> On Nov 29, 2018, at 10:55 AM, Pavel Labath via Phabricator > <revi...@reviews.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.
Since the Breakpad files contain symbol and debug info, I would make a ObjectFileBreakpad and SymbolFileBreakpad route. We might want to just load a break pad file and be able to symbolicate with it. Each symbol vendor will need to be able to use a breakpad file (since Breakpad produces files for all architectures), so we can build some functionality into the SymbolVendor base class for file formats that any file format (ELF, Mach-o, COFF) might want to use. > > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D53368/new/ > > https://reviews.llvm.org/D53368 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
