[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Fri Dec 14 05:44:04 PST 2018


On 13/12/2018 23:19, Zachary Turner wrote:
> The permanent solution would be figuring out what to do about the 
> ObjectFile situation (e.g. do we want to make an ObjectFilePDB or do we 
> want to live in a world where SymbolFiles need not be backed by 
> ObjectFiles?), and then regardless of what we decide there, implementing 
> the SymbolVendor that can search a combination of locations including 
> (but not limited to) a symbol server.  lldb already has the notion of a 
> symbol path.  So using this we could just use that existing logic to 
> search the symbol path, and before you run LLDB make sure your minidump 
> .pdb files are in that search path.  If we make an ObjectFilePDB, then 
> this should be able to fall out naturally of the existing design with no 
> additional work, because it will use the normal SymbolVendor search 
> logic.  If we allow SymbolFilePDB to live without an ObjectFilePDB, then 
> we would have to make changes similar to what you proposed earlier where 
> we can still get a SymbolVendor and use it to execute its default search 
> algorithm, plus probably some other changes to make sure various other 
> things work correctly in the presence of ObjectFile-less SymbolFiles.
> 

+1 for that.


I'm particularly interested in the result of this, as I'm in the middle 
of adding ObjectFileBreakpad, whose raison d´être is to make things 
interoperate more nicely with the rest of lldb.

My take on this is that going the ObjectFile route is going to be faster 
and less intrusive, but it may produce some odd-looking APIs. E.g. maybe 
the ObjectFilePDB will claim it contains no sections (which is the 
traditional way of passing information from ObjectFiles to SymbolFiles), 
but instead provide some private API to access the underlying llvm data 
structures, which will be used by SymbolFilePDB to do it's thing.

OTOH, object-less symbol files has the potential to produce 
nicer-looking APIs overall, but it will require a lot of changes to core 
lldb to make it happen. E.g., besides the fact that searching for 
"symbols" happens on the object file level (which is the whole reason 
we're having this discussion), the object files are also responsible for 
providing unwind information. That would have to change too.


More information about the lldb-commits mailing list