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.

lldb-dev mailing list

Reply via email to