Yes, I agree that the current model of object files - symbol files - symtabs is not clear and orthogonal for cases like PDB, and I think that it requires some redesign too.
But can we commit this patch now to proceed with several dependent (and not directly related to the theme) patches? When a new model of work with symbol files will be approved I'm ready to help with fixing the PDB part to conform it. Am Do., 29. Nov. 2018, 22:18 hat Leonard Mosescu <mose...@google.com> geschrieben: > Great observations Pavel! I think it's really important to have > orthogonal/composable abstractions here: the symbols should be decoupled > from the container format IMO. > > You know more about the ObjectFile than me so I can't say if > ObjectFileBreakpad is the best interface, but here are my initial > observations (in a somewhat random order): > > 1. We need clear and separate abstractions for a container (ELF, PE file, > Breakpad symbols) vs. the content (debug Information). > > 2. We need to be able to consume symbols when the corresponding module > binary is not available. This is common for postmortem debugging (ex. > having a minidump + PDBs, but not all the .DLLs or EXE files). > > 3. I'm not a fan of the PDB model, where the symbols are searched in both > the symtabs then in the symbol files. I'd rather like to see the symtab an > interface for symbols regardless of where they come from. > (Zach expressed some efficiency concerns if we'd need to build a symtab > from a PDB for example as opposed to accessing the PDB symfile directly, > although I think we can design to address this - ie. multiple concrete > symtab implementations, some of which are *internally* aware of the source > container, but w/o leaking this through the interface) > > 4. The symbol vendor observation is very important. Right now LLDB has > basic support for looking up DWARF symbols and none for PDBs. (for example, > IMO LLDB could greatly benefit from something like Microsoft's symsrv - I'm > actually planning to look into it soon) > (Whatever we do, this should be one of the key requirements IMO) > > I have a local change to address #2 specifically for PDBs (I'll try to > send out a code review soon). > > On Thu, Nov 29, 2018 at 10:55 AM Pavel Labath via Phabricator via > lldb-commits <lldb-commits@lists.llvm.org> wrote: > >> labath added a comment. >> >> I've recently started looking at adding a new symbol file format >> (breakpad symbols). While researching the best way to achieve that, I >> started comparing the operation of PDB and DWARF symbol files. I noticed a >> very important difference there, and I think that is the cause of our >> problems here. In the DWARF implementation, a symbol file is an overlay on >> top of an object file - it takes the data contained by the object file and >> presents it in a more structured way. >> >> However, that is not the case with PDB (both implementations). These take >> the debug information from a completely different file, which is not backed >> by an ObjectFile instance, and then present that. Since the SymbolFile >> interface requires them to be backed by an object file, they both pretend >> they are backed by the original EXE file, but in reality the data comes >> from elsewhere. >> >> If we had an ObjectFilePDB (which not also not ideal, though in a way it >> is a better fit to the current lldb organization), then this could expose >> the PDB symtab via the existing ObjectFile interface and we could reuse the >> existing mechanism for merging symtabs from two object files. >> >> I am asking this because now I am facing a choice in how to implement >> breakpad symbols. I could go the PDB way, and read the symbols without an >> intervening object file, or I could create an ObjectFileBreakpad and then >> (possibly) a SymbolFileBreakpad sitting on top of that. >> >> The drawbacks of the PDB approach I see are: >> >> - I lose the ability to do matching of the (real) object file via symbol >> vendors. The PDB symbol files now basically implement their own little >> symbol vendors inside them, which is mostly fine if you just need to find >> the PDB next to the exe file. However, things could get a bit messy if you >> wanted to implement some more complex searching on multiple paths, or >> downloading them from the internet. >> - I'll hit issues when attempting to unwind (which is the real meat of >> the breakpad symbols), because unwind info is currently provided via the >> ObjectFile interface (ObjectFile::GetUnwindTable). >> >> The drawbacks of the ObjectFile approach are: >> >> - more code - it needs a new ObjectFile and a new SymbolFile class >> (possibly also a SymbolVendor) >> - it will probably look a bit weird because Breakpad files (and PDBs) >> aren't really object files >> >> I'd like to hear your thoughts on this, if you have any. >> >> >> CHANGES SINCE LAST ACTION >> https://reviews.llvm.org/D53368/new/ >> >> https://reviews.llvm.org/D53368 >> >> >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits >> >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits