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

Thu Nov 29 12:29:37 PST 2018

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.urakov at 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 <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/8ff5b568/attachment-0001.html>