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.
Details
Diff Detail
- Build Status
Buildable 7458 Build 7458: arc lint + arc unit
Event Timeline
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.
lld/COFF/PDB.cpp | ||
---|---|---|
137 | Use the concrete type instead of auto. | |
142–144 | You probably want to use fatal as this code handles broken input files. | |
152–158 | 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 | Can you break a line here | |
172 | and here so that this doesn't look like one big chunk of code. |
lld/COFF/PDB.cpp | ||
---|---|---|
142–144 | 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. |
lld/COFF/PDB.cpp | ||
---|---|---|
142–144 | 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. |
Looks like this should be an error too.