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

In D53368#1313145 <https://reviews.llvm.org/D53368#1313145>, @zturner wrote:

> In D53368#1313124 <https://reviews.llvm.org/D53368#1313124>, @labath wrote:
>
> > 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.
>
>
> Don't DWARF DWP files work this way as well?  How is support for this implemented in LLDB?


There are some similarities, but DWP is a bit different. The main difference is that the DWP file is still an ELF (or whatever) file, so we still have a ObjectFile sitting below the symbol file. The other difference is that in case of DWP we still have a significant chunk of debug information present in the main executable (mainly various offsets that need to be applied to the unlinked debug info in the dwo/dwp files), so you can still very well say that the symbol file is reading information from the main executable. What DWARF does in this case is it creates a main SymbolFileDWARF for reading data from the main object file, and then a bunch of inner SymbolFileDWARFDwo/Dwp instances which read data from the other files. There are plenty of things to not like here as well, but at least this maintains the property that each symbol file sits on top of the object file from which it reads the data from. (and symtab doesn't go into the dwp file, so there are no issues with that).

>> 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.
> 
> What if `SymbolFile` interface provided a new method such as `GetSymtab()` while `ObjectFile` provides a method called `HasExternalSymtab()`.  When you call `ObjectFilePECOFF::GetSymtab()`, it could first check if `HasExternalSymtab()` is true, and if so it could call the SymbolFile plugin and return that

I don't think this would be good because there's no way for the PECOFF file to know if we will have a PDB file on top of it. If we don't find the pdb file, then the best we can do is use the list of external symbols as the symtab for the PECOFF file. I think a better way would ask the SymbolFile for the symtab. Then the symbol file can either return it's own symtab, or just forward the symtab from the object file (we already have a SymbolFileSymtab for cases when we have no debug info). That is more-or-less what this patch is doing, except that here the SymbolFile is inserting it's own symbols into the symtab created by the object file.


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

https://reviews.llvm.org/D53368