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?
lldb-dev mailing list