Hi Pavel, I'm open to this. I don't think there was any specific reason why UnwindTable is in the ObjectFile over the Module - it was very likely not an intentional choice when I put it there.
To recap, each "binary" in the system has an UnwindTable. The UnwindTable has a list of functions it has unwind plans for, and it has a list of sources of unwind sources that it can get from object files. The UnwindTable starts with a full list of unwind tables and no For every function that we've parsed unwind information, we create a FuncUnwinder object which the UnwindTable stores. Some unwind information is expensive to get -- scanning the instructions, for instance -- so we only want to do this on-demand, and we don't want to do it twice in the same debug session. FuncUnwinders has a variety of public methods (probably more than it should) but at a high level, users of this object ask it "give me the best unwind plan if this function is currently-executing aka on the 0th stack frame" or "give me the best unwind plan if this function is in the middle of the stack". RegisterContextLLDB / UnwindLLDB are the main bits of code that call these methods. FuncUnwinders gets the different unwind sources from UnwindTable (e.g. eh_frame, compact_unwind, debug_info) or via a Thread object at run-time for unwind sources that require an executing runtime (instruction profiling) (and some unwind plans from the ABI plugin via the Thread). Are you proposing removing the hardcoded rules in FuncUnwinders of which unwind plan sources to prefer in different situations? I'm not against it, but the # of unwind sources has been small enough that it hasn't been too much of a problem imo. If we wanted to do it algorithmically, I think the important attributes for an unwind plan are whether it is (1) known to be accurate at every instruction location, (2) known to be accurate only at throwable locations. And whether it is (a) sourced directly from the compiler or (b) constructed heuristically (assembly instruction analysis, eh_frame augmentation via instruction analysis). eh_frame and debug_frame are the most annoying formats because they CAN be accurate at every instruction location, if the producer decided to do that. Or they may only be accurate for the prologue. (often called "asynchronous unwind tables" when it is accurate at every instruction) But there's nothing in the eh_frame/debug_frame spec that tells the consumer (lldb) what kind of unwind source this is. Well anyway, that's a lot of words - but in short, if it makes something easier for you to move UnwindTable into Module, I don't see any problems with that. Making a cleaner way of getting unwind sources, or deciding between them, I'm interested to see what that might look like. The current setup is a lot of manual coding, but then again there aren't a very large number of unwind sources so far. J On 02/07/19 08: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 > <signatureafterquotedtext></signatureafterquotedtext>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
