We also have information that is generated, like assembly unwind, ABI plug-ins (I believe) which give out the arch defaults for how to unwind at the first instruction of the function, and also one that unwinds when you are in the middle (follow the frame pointer and PC is at FP-<ptrsize>). It would be great if this could live in the Module and also be generated without having to have a live process. Many tools I know of would love to be able to get to and enumerate our unwind info via the public API, especially the assembly unwind info.
Jason us the unwind guy, so his opinion is important. The overall approach sounds good to me though. Module is the coordinator of one or more object files and symbol files, so this makes sense to me. Greg > On Feb 7, 2019, at 8:54 AM, Pavel Labath <pa...@labath.sk> wrote: > > 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? > > regards, > pavel _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
