<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 12, 2016 at 9:41 AM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 11, 2016, at 6:56 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
><br>
> > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I want to make a new symbol provider to teach LLDB to understand microsoft PDB files.  I've been looking over the various symbol APIs, and I have a few questions.<br>
> ><br>
> > 1. Under what circumstances do I need a custom SymbolVendor?  The way pdb works is that generally there is 1 file that contains all the debug info needed for a single binary (so or executable).  Given a list of paths, we can then determine if there is a matching PDB in one of those paths.  Is it better to do this in the CalculateAbilities() function of the symbol file plugin (by just returning 0 if we don't find a match) or do we need to do something more complicated?<br>
><br>
> I would suggest make a SymbolVendorPDB that only enables itself if you are able to find the PDB files for your COFF file. So look at your COFF file, and I presume somewhere in there there is a pointer to one or more PDB files inside that file? CalculateAbililties is the correct place to see if a COFF file has pointers to PDB files and making sure those files exist before you say that you can provide any abilities.<br>
> Currently we use the operating system to query the PDBs.  This could change in the future, but for now that's how we're doing it.  The operating system does all the work of finding, matching, and loading the PDB for us, and it does it all in one call.  So if we put this in the symbol vendor, there's no way to say "is there a PDB" without also saying "actually load all the data from the PDB" at the same time.  So I'm not sure if there's a solution to this in there, because obviously I dont' want to load it twice.<br>
<br>
Interesting. If you are on windows and you have a COFF file, you might just want to make a SymbolVendorCOFF. Does PDB info always and only get created for COFF files?<br></blockquote><div>Yes.  What's the disadvantage to just using the default SymbolVendor implementation, and just having the SymbolFilePDB plugin, when it's created, attempt to locate the PDB and just return 0 abilities if it can't find a match?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> One question I had about SymbolVendor, is that I looked at SymbolVendorELF.cpp and it seems to boil down to this notion of "symbol file representations".  All the logic in SymbolVendorELF exists just to add some object file representations.  What is this supposed to represent?  I've got an exe or something, what other "representation" is there other than the exe itself?<br>
<br>
In SymbolVendoerMacOSX, we have the executable and then the DWARF debug info in a stand alone dSYM bundle. So MacOSX you have a.out as the main ObjectFile (a.out) for a Module, but the symbols are in a different ObjectFile (a.out.dSYM). For ELF I believe there is information in the ELF file that _might_ point to a separate debug info file, but it also might just contain the DWARF in the executable. So for ELF you have 1 file (exec ELF that contains DWARF) or two files (exe ELF with no DWARF + debug info ELF with DWARF).<br></blockquote><div>Why does AddSymbolFileRepresentation take an ObjectFile though?  A PDB is not an object file, so if we went and looked for a matching PDB, downloaded it from our build server, and wanted to use it, we couldn't exactly call AddSymbolFileRepresentation(pdb) because we wouldn't have an ObjectFile, we'd have a PDB.  Maybe we'd need an overload of this function that just takes a SymbolFile* directly so that the vendor could add the SymbolFile it finds.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A symbol vendor's only job is to take an executable and and then use it plus any other files (its job is to locate these extra debug files) to make a single coherent view of the symbols for a lldb_private::Module. So the SymbolVendor::FindTypes(...) might look into the executable file and one or more other files to get the information. The information must be retrieved from one or more SymbolFile instances. A SymbolFile uses one ObjectFile to do its job. So there is a one to one mapping between SymbolFile and ObjectFile instances. The SymbolFile can use the same ObjectFile as the main executable if the data is in there. The SymbolVendor is the one that figures this out.<br></blockquote><div>So in this case, there are no extra files.  One object file (COFF) is all you need to locate the 1 PDB file.  So we should be able to assume a 1-to-1 mapping between modules and SymbolFile instances.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
So think of SymbolVendor as the class that knows how to locate the symbol file for a given executable (possibly even fetch the symbols from your build system!!!) </blockquote><div>We will definitely need something like this later, so I could see this being useful down the road.  For now it seems like we can get by with just having a SymbolFilePDB class and using the default vendor implementation.</div><div><br></div></div></div>