> On Nov 29, 2018, at 3:31 PM, Zachary Turner <ztur...@google.com> wrote: > > Objects have a symbol table, but a Module is just a loaded object file. And a > loaded object file can have multiple symbol tables (from the object file, or > symbol file, etc). > > Would it make sense to have Module provide a GetSymtab method that can find > all appropriate Symtabs and present a unified view?
That is exactly what currently happens. Module just lets the symbol vendor do the work of gathering all files (executable + dSYM for Mac, executable + external debug info file for ELF, etc). So yes, the goal is the module provides the view a user wants to see and uses the symbol vendor to help get that view. Greg > On Thu, Nov 29, 2018 at 2:39 PM Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: > > > > On Nov 29, 2018, at 2:02 PM, Zachary Turner via Phabricator > > <revi...@reviews.llvm.org <mailto:revi...@reviews.llvm.org>> wrote: > > > > zturner added a comment. > > > > In D53368#1313238 <https://reviews.llvm.org/D53368#1313238 > > <https://reviews.llvm.org/D53368#1313238>>, @labath wrote: > > > >> In D53368#1313145 <https://reviews.llvm.org/D53368#1313145 > >> <https://reviews.llvm.org/D53368#1313145>>, @zturner wrote: > >> > >>> In D53368#1313124 <https://reviews.llvm.org/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. > > > > > > I'm actually starting to wonder even if `GetSymtab()` should be part of > > `ObjectFile`. The first thing it does is get the Module and then start > > calling a bunch of stuff on the Module interface. Perhaps the place to > > start is comparing the Module and ObjectFile interfaces and seeing if the > > existing APIs make the most sense being moved up to Module. If everything > > was on Module then the Module has everything it needs to go to the > > SymbolVendor and find a PDB file. > > I would vote against moving anything into the module. Object files have their > own symbol tables and we need the ability for an object file to be able to > find a symbol that it created and we really don't want to abstract this away > since at any time when we delve further into an object file we might need to > dig up a symbol by its original symbol table index. So the cleanest design in > my opinion is one where the object files can each have their own symbol table > and the module uses the symbol vendor to get promote the best information up > to the user. Symbols can come from one object file, or an external debug info > object file, or from Breakpad. But each of those files should be able to have > their own notion of their own symbols. > > Greg > > > > > > > CHANGES SINCE LAST ACTION > > https://reviews.llvm.org/D53368/new/ <https://reviews.llvm.org/D53368/new/> > > > > https://reviews.llvm.org/D53368 <https://reviews.llvm.org/D53368> > > > > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
