[lldb-dev] RFC: Unwinding + Symbol Files: How To?

[Pavel Labath via lldb-dev]

Hello Jason, Greg,

thank you for the feedback. Please find my responses inline.


On 08/02/2019 04:06, Jason Molenda wrote:
> 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.
Cool. Thanks.

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

At the moment, probably not. I've played around with the idea while 
experiment and trying to figure out how to make this work, but I haven't 
been able to come up with something which is significantly better than 
the current code. So, I'll probably just insert this new "symbol file 
unwind plan" into the hardcoded list of priorities. TBH, the exact place 
probably doesn't matter much since it is unlikely that a single function 
would have both eh_frame data and pdb/breakpad unwind info.

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



On 07/02/2019 19:18, Greg Clayton wrote:
 > 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.

I am also interested in something like that, though this will probably 
be a separate endeavour and not a part of getting making breakpad unwind 
info parsing effort.

regards,
pavel