[lldb-dev] Making a new symbol provider

[Zachary Turner via lldb-dev]

Hi,

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.

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?

2. Why is there a function called ParseCompileUnitLanguage?  The
CompileUnit class already stores the language when ParseCompileUnit is
called, and ParseCompileUnitLanguage is implemented by just getting that
value out.  What is the poitn of this function?

3. There's a function called ParseCompileUnitDebugMacros.  Is this
referring to C / C++ macros?  Like #define FOO 7?  What is that used for?
I don't believe info about preprocessor definitions are stored in PDB.  Is
this going to cause problems?

4. ParseCompileUnitSupportFiles.  What are "support files"?  Given a file
"foo.cpp" is this supposed to be header files etc?

5. ParseCompileUnitLineTable.  On the LineTable class you can add "line
sequences" or individual entries.  What's the difference here?  Is there
any disadvantage to adding every single line entry in the line table using
the InsertLineEntry instead of building a line sequence and inserting the
sequence?

I will probably have some more questions as I continue down this path.  For
now I'm planning to implement the minimum amount of functionality required
just to make LLDB locate and open a PDB for an executable without actually
returning anything useful from it.  So when I start filling out types,
functions, etc I may have some more questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160211/095df872/attachment.html>