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 

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 

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.


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

Reply via email to