[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

Thu Nov 29 12:08:31 PST 2018

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 <mosescu at 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 at 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 at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181129/bbd4803a/attachment.html>