Re: Frame unwind functions

[Andrew Cagney <ac131313@redhat.com>]

> Andrew Cagney wrote:
> Hi all,
> since there are different unwind mechanisms in different branches of GDB I got a bit lost. I need to sort my thoughts to understand the principles.
> 
> First my view of how things now work:
> 
> To be honest, this a very good description of how GDB did work: special case on top of special case on top of ....
> 
> Thanks for appreciation :-)
> But I'm afraid you didn't understand me. AFAIK these special cases are still in there, but now they're hidden in appropriate unwind function sets. You were talking about the interface (frame_unwind_register, frame_unwind_id, ...) while I was talking about the internals of these methods for different frame types. That's what I'm interested in if I should implement these methods for different x86-64 frames - I'm examining what other types of frame unwinders do to know what my ones should do.

Ah, ok.  An architecutre could potentially have the following unwinders:

- traditional (prologue based)
- sigtramp

The x86-64 GNU/Linux, appears to only have the second.  In addition, 
there is the generic:

- cfi

unwinder.

> - In the backtrace the function's arguments are printed as well.
>   - on i386 it's not a problem since they are on the stack
>   - on x86-64 we pass some of them in registers
>     - that's fine for the first frame (#0) - I know all registers and I
>       can use location lists to find current position of a given arg.
>     - for the second frame (#1) I could call
>       next_frame->unwind->reg(regnum) to get the register I need and
>       unwind it even more by calling this_frame->unwind->reg(regnum) to
>       get it's value at the beginning of the frame.
>     - but how about the next frames (#2,...)? I can always call
>       next_frame->unwind->reg(regnum) and if the next_frame wouldn't
>       know its "initial" value (ie. the value at the place of PC) it
>       would recursively call next_frame->next_frame->unwind->register()
>       untill it get's the value.
> 
> 
> The above is the desired and correct behavior.  This recursion is required for things to work (a stack is recursive by definition).
> 
> What if a desired register's value isn't available anymore? How do I report it to the caller of my_frame->unwind->reg()? By setting an optimizedp parameter?

Yes, at present setting optimized to non-zero is the best there is.  I 
noticed that the cfi unwinder is already doing this.

Andrew