Initial changes to support debugging PECOFF/PDB files using LLDB through the DIA SDK
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Nice! I'm looking forward to reviewing this tomorrow.
I'm adding it for you here, but please include llvm-commits@ as a subscriber in the future. Also check the To/Cc fields on this response when it hits your Inbox. If you don't see llvm-commits@ anywhere, you may need to abandon and re-create this revision (Phabricator can be finnicky)
Looks good, mostly just nitpicks. Can you also add a test for this? We've checked in an several actual PDBs into test/tools/llvm-pdbutil/Inputs, but you'd need to add a command line option to the pretty mode of llvm-pdbutil so that it can dump it. Perhaps making it a hidden option. Hopefully the PDBs that are checked in already will cause DIA to return something interesting for the tables.
include/llvm/DebugInfo/PDB/DIA/DIARawSymbol.h | ||
---|---|---|
99 ↗ | (On Diff #121203) | Can we make this an enum, similar to how we have PDB_NameSearchFlags in this same file. |
include/llvm/DebugInfo/PDB/IPDBRawSymbol.h | ||
111 ↗ | (On Diff #121203) | enum if possible |
include/llvm/DebugInfo/PDB/PDBTypes.h | ||
77–86 ↗ | (On Diff #121203) | None of these values are well documented. I'm assuming you understand the format of the content in these tables, so if so would you mind adding a comment before the enumeration? Or if it depends too heavily on the enum value, a comment next to each value. For example, I can hypothesize that the Symbols contains a chunk of CodeView records, but what does that correspond to in the underlying PDB? Is it literally direct access to the globals stream? or the publics stream? Or something else? Same for line numbers. It would be nice, while you're here, if you could expand a little bit on what people can expect to get out of these tables, because I honestly don't know. There's some vague hints about it here, but this page does not mention InputAssemblyFiles or Dbg at all, so it's unclear what we can expect to find in these tables. |
250 ↗ | (On Diff #121203) | Can this be a flags enum like PDB_NameSearchFlags instead of some #defines? We also don't need to adhere firmly to the Microsoft definition names, so we can camel-case them in traditional LLVM style. |
lib/DebugInfo/PDB/DIA/DIATable.cpp | ||
40 ↗ | (On Diff #121203) | Can you do an early return here if it fails? Same with the rest of the cases, we can remove all the elses because each if will just return early. |
We'll take a look at what we can do with llvm-pdbutil to test these changes. Right now we are only using publicly available information and I'm not sure I can say much more about what DIA SDK does beyond what you can already see online. I'll ask if there is some better information we can share.
Sounds fair. I won't block over this for now, so let me look at the changes you made as they are.
Actually I think ignore my comment about the documentation. The contents (as in the internal format) is not documented, but that's obviously for good reason. And anyway, it's not really the internal format that's interesting, it's more the high level "what even is this?" And for that, I think we can figure that out by experimentation. All of these "tables" are really just com interfaces that enumerate something. We can investigate what they enumerate by just experimenting.
There is another set of changes for LLDB coming with lots of unit tests in a week or so. This is the practice code review :)