This is an archive of the discontinued LLVM Phabricator instance.

[PDB] Add symbols to the PDB
ClosedPublic

Authored by rnk on Jun 20 2017, 5:23 PM.

Details

Summary

The main complexity in adding symbol records is that we need to
"relocate" all the type indices. Type indices do not have anything like
relocations, an opaque data structure describing where to find existing
type indices for fixups. The linker just has to "know" where the type
references are in the symbol records. I added an overload of
discoverTypeIndices that works on symbol records, and it seems to be
able to link the standard library.

Diff Detail

Repository
rL LLVM

Event Timeline

rnk created this revision.Jun 20 2017, 5:23 PM
zturner edited edge metadata.EditedJun 20 2017, 5:41 PM

Since we already merge type streams, can you write a test that verifies that these are re-written correctly after linking? Right now the only symbols in the test output have simple type indices (e.g. int), it would be nice to see some symbols in there that refer to non-simple types that have moved around during the type merging process.

rnk added a comment.Jun 20 2017, 5:47 PM

Since we already merge type streams, can you write a test that verifies that these are re-written correctly after linking? Right now the only symbols in the test output have simple type indices (e.g. int), it would be nice to see some symbols in there that refer to non-simple types that have moved around during the type merging process.

In theory the S_GPROC32_ID record should exercise that, but the minimal dumper doesn't print item ids. I can hack on that first, and then we don't need another test.

rnk added a comment.Jun 20 2017, 6:12 PM
In D34432#786170, @rnk wrote:

Since we already merge type streams, can you write a test that verifies that these are re-written correctly after linking? Right now the only symbols in the test output have simple type indices (e.g. int), it would be nice to see some symbols in there that refer to non-simple types that have moved around during the type merging process.

In theory the S_GPROC32_ID record should exercise that, but the minimal dumper doesn't print item ids. I can hack on that first, and then we don't need another test.

Eh, who am I kidding. We should have a test that goes on and exercises as many symbol records as possible. I'll put that together.

rnk updated this revision to Diff 103314.Jun 20 2017, 6:19 PM
  • add S_UDT test
ruiu added inline comments.Jun 20 2017, 7:34 PM
lld/COFF/PDB.cpp
137 ↗(On Diff #103300)

Use the concrete type instead of auto.

142–144 ↗(On Diff #103300)

You probably want to use fatal as this code handles broken input files.

152–158 ↗(On Diff #103300)

I guess you are adding more cases in future, but for now please avoid using switch as we have only two choices. It can be written as if (...) return S_END; return Kind;.

168 ↗(On Diff #103300)

Can you break a line here

172 ↗(On Diff #103300)

and here so that this doesn't look like one big chunk of code.

rnk marked 4 inline comments as done.Jun 21 2017, 9:20 AM
rnk added inline comments.
lld/COFF/PDB.cpp
142–144 ↗(On Diff #103300)

It's more likely that our understanding of the record is broken that it is for the record to actually be corrupt. This line actually fires today for files compiled with /Zi, because there's something wrong with our type server handling. libcmt.lib was compiled with /Zi, so any program using the CRT hits this.

I'd rather recover by skipping the record for now. It doesn't result in a broken program, just a less useful PDB.

rnk updated this revision to Diff 103406.Jun 21 2017, 9:20 AM
  • formatting
ruiu added inline comments.Jun 21 2017, 9:26 AM
lld/COFF/PDB.cpp
134 ↗(On Diff #103406)

Looks like this should be an error too.

192 ↗(On Diff #103406)

error?

142–144 ↗(On Diff #103300)

Then can you use error(), which does not call exit?

rnk added inline comments.Jun 21 2017, 10:15 AM
lld/COFF/PDB.cpp
142–144 ↗(On Diff #103300)

I don't want to fail the link, though, so this should ultimately be a warning. It's a "log" for now so that it only shows up under verbose output, because you get 100s of these messages when linking against the STL. We can promote it to a warning later.

The scenario I'm imagining is that MSVC starts emitting a new optimized debug info record that we don't understand. IMO, LLD should ignore the record and emit a warning.

ruiu accepted this revision.Jun 21 2017, 10:16 AM

LGTM

This revision is now accepted and ready to land.Jun 21 2017, 10:16 AM
This revision was automatically updated to reflect the committed changes.