[lldb-dev] RFC: Unwinding + Symbol Files: How To?

Pavel Labath via lldb-dev lldb-dev at lists.llvm.org
Thu Feb 7 08:54:22 PST 2019

Hello all,

currently I am at at stage where the only large piece of functionality 
missing from the Breakpad symbol file plugin is the unwind information. 
The PDB plugin has been in that state for a while. I'd like to rectify 
this situation, but doing that in the present lldb model is somewhat 

The main problem is that in the current model, the unwind strategies are 
a property of the ObjectFile. I am guessing the reason for that is 
historical: most of our unwind strategies (instruction emulation, 
eh_frame, ...) are independent of symbol file information. One exception 
here is debug_frame, which is technically a part of DWARF, but in 
reality is completely independent of it, so it's not completely 
unreasonable to for it to be implemented outside of SymbolFileDWARF.

However, I don't think this is a good strategy going forward. Following 
the current approach the parsing code for breakpad and pdb unwind info 
would have to live somewhere under source/Symbol, but these are pretty 
specialist formats, and I don't think it makes sense to pollute generic 
code with something like this.

Therefore, I propose to modify the current model to allow SymbolFile 
plugins to provide additional unwind strategies. A prerequisite for that 
would be moving the unwind data source handling code (UnwindTable class) 
from ObjectFile to Module level.

The overall idea I have is to have the Module, when constructing the 
UnwindTable, consult the chosen SymbolFile plugin. The plugin would 
provide an additional data source (hidden behind some abstract 
interface), which could be stored in the UnwindTable, next to all other 
sources of unwind info. Then the unwind strategy (class UnwindPlan) 
generated by this source would be considered for unwinding along with 
all existing strategies (relative priorities TBD).

Any thoughts on this approach?


More information about the lldb-dev mailing list