Hi Aleksandr, yes, no objections to this patch. I was responding to Pavel's comments, which I also assume are forward-looking as well, not strictly related to this patch.
On Thu, Nov 29, 2018 at 12:08 PM Aleksandr Urakov < aleksandr.ura...@jetbrains.com> wrote: > 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
