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 challenging.

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

Reply via email to