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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

> 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):

Even though it doesn't sound like that, ironically, Breakpad might be now better of as an ObjectFile rather than a SymbolFile. The main three pieces of information contained in breakpad files are:

- list of symbols
- unwind information
- line tables

Of these, the first two are presently vended by object files, and only the line table is done by symbol files. The auxiliary pieces of information in the breakpad files (architecture, OS, UUID), are also a property of object files in lldb.

> 1. We need clear and separate abstractions for a container (ELF, PE file, Breakpad symbols) vs. the content (debug Information).

I agree, unfortunately I think we're quite far from that now. This is complicated by the fact that different "symbol file" formats have different notion of what "symbols" are. E.g. it's obvious that Symtab ended up being vended by the object files because that's how elf+macho/dwarf do things, but that's not the case for pecoff/pdb.

> 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).

This is also going to be a bit tricky, though slightly orthogonal requirement. Right now things generally assume that a Module has an ObjectFile to read the data from, even though ProcessMinidump tries to work around that with special kinds of Modules. That might be enough to make addresses resolve somewhat reasonably, but I'm not sure what will happen once we start providing symbols for those kinds of modules.

> 
> 
> 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)

I am afraid I am a bit lost here, as I don't know much about PDBs. I'll have to study this in more detail.

> 
> 
> 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)

agreed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53368/new/

https://reviews.llvm.org/D53368