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

Leonard Mosescu via lldb-commits lldb-commits at lists.llvm.org
Thu Nov 29 11:17:59 PST 2018


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/ac4a1156/attachment.html>


More information about the lldb-commits mailing list