Unwinding dummy frames on the i386

Unwinding dummy frames on the i386

[Mark Kettenis]

Hi Andrew,

After you committed the unwind_dummy_id stuff, I'm having some
problems getting the i386 target working again.

I tried using generic_save_dummy_frame on this target.  This works
fine if we're unwinding from a normal frame into a dummy frame.
However, if we're unwinding from a sentinel frame, things start to get
a bit difficult.  This basically happens if we've hit the special
breakpoint upon return from the called function.  On the i386
returning from a function pops the return address from the stack.
Since the return address was pushed by GDB an accounted for in the
stack pointer passed to generic_save_dummy_frame_tos(), things don't
match up.  This fixable in i386_unwind_dummy_id(), however things are
a bit more complicated.

If a function returns a struct, the caller is supposed to push as a
"hidden" parameter the address of a bit of memory where the called
function is supposed to store the struct.  This extra push is again
accounted for in the stack pointer passed to
i386_save_dummy_frame_tos().  However, since the called function is
supposed to remove this address from the stack, again things don't
match up for the unwind-from-sentinel case.  I don't see a clean way
to fixup this.

For now I've worked around this by having my own do-nothing
i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return
contents of the (saved) frame pointer register for the frame's base.
Is there a better way to solve this?

Mark

Re: Unwinding dummy frames on the i386

[Andrew Cagney]

> For now I've worked around this by having my own do-nothing
> i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return
> contents of the (saved) frame pointer register for the frame's base.
> Is there a better way to solve this?

Can i386_save_dummy_frame_tos() save the `frame pointer register' that 
the unwind_dummy_id() method later returns?

While the TOS in save_dummy_frame_tos() might have once stood for 
top-of-stack, there isn't anything saying that it has to be the stack 
top.  A better name for tha functioin's successor would be 
save_dummy_frame_id()

Andrew

Re: Unwinding dummy frames on the i386

[Mark Kettenis]

   Date: Fri, 07 Mar 2003 17:13:24 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   > For now I've worked around this by having my own do-nothing
   > i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return
   > contents of the (saved) frame pointer register for the frame's base.
   > Is there a better way to solve this?

   Can i386_save_dummy_frame_tos() save the `frame pointer register' that 
   the unwind_dummy_id() method later returns?

If reading the current value of FP_REGNUM from current_regcache is OK
the answer is yes.  Hmm, in that case it's probably an even better
idea to actually set the frame pointer register to the top-of-stack in
i386_save_dummy_frame_tos().  That way, we won't have a problem when
there are several frameless function calls in a row.  Is writing into
current_regcache acceptable?

   While the TOS in save_dummy_frame_tos() might have once stood for 
   top-of-stack, there isn't anything saying that it has to be the stack 
   top.  A better name for tha functioin's successor would be 
   save_dummy_frame_id()

Agreed.

Mark

Re: Unwinding dummy frames on the i386

[Andrew Cagney]

>    Date: Fri, 07 Mar 2003 17:13:24 -0500
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    > For now I've worked around this by having my own do-nothing
>    > i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return
>    > contents of the (saved) frame pointer register for the frame's base.
>    > Is there a better way to solve this?
> 
>    Can i386_save_dummy_frame_tos() save the `frame pointer register' that 
>    the unwind_dummy_id() method later returns?
> 
> If reading the current value of FP_REGNUM from current_regcache is OK
> the answer is yes.

Yes.  Just add a comment to gdbarch.sh saying that tos's successor needs 
to be explicitly parameterized with the new regcache (along with 
anything else that might prove useful - old regcache, struct_addr, bp 
addr :-).

 > Hmm, in that case it's probably an even better
> idea to actually set the frame pointer register to the top-of-stack in
> i386_save_dummy_frame_tos().  That way, we won't have a problem when
> there are several frameless function calls in a row.  Is writing into
> current_regcache acceptable?

Shouldn't the push arguments code have already adjusted the FP?

Anyway, regardless, you want to add frame_align() to the i386 
architecture vector.  It forces a non-empty correctly aligned dummy 
frame (thus eliminating the frameless dummy frame problem) (but read the 
comments that go with the call).

> 
>    While the TOS in save_dummy_frame_tos() might have once stood for 
>    top-of-stack, there isn't anything saying that it has to be the stack 
>    top.  A better name for tha functioin's successor would be 
>    save_dummy_frame_id()
> 
> Agreed.

Andrew

Re: Unwinding dummy frames on the i386

[Mark Kettenis]

   Date: Sat, 08 Mar 2003 10:20:08 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   >    Date: Fri, 07 Mar 2003 17:13:24 -0500
   >    From: Andrew Cagney <ac131313@redhat.com>
   > 
   >    > For now I've worked around this by having my own do-nothing
   >    > i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return
   >    > contents of the (saved) frame pointer register for the frame's base.
   >    > Is there a better way to solve this?
   > 
   >    Can i386_save_dummy_frame_tos() save the `frame pointer register' that 
   >    the unwind_dummy_id() method later returns?
   > 
   > If reading the current value of FP_REGNUM from current_regcache is OK
   > the answer is yes.

   Yes.  Just add a comment to gdbarch.sh saying that tos's successor needs 
   to be explicitly parameterized with the new regcache (along with 
   anything else that might prove useful - old regcache, struct_addr, bp 
   addr :-).

Will do.

   > Hmm, in that case it's probably an even better
   > idea to actually set the frame pointer register to the top-of-stack in
   > i386_save_dummy_frame_tos().  That way, we won't have a problem when
   > there are several frameless function calls in a row.  Is writing into
   > current_regcache acceptable?

   Shouldn't the push arguments code have already adjusted the FP?

Not necessarily.  It's the job of the called function to set up the FP
(if it needs one or otherwise chooses to do so, e.g. for the benefit
of a debugger).  The called function doesn't care what the value of
the FP is.  The only reason I'm trying to set up a FP is for us to be
able to find the right dummy frame upon unwinding.  Therefore I'd like
to restrict fiddling with the FP to save_dummy_frame_tos().

   Anyway, regardless, you want to add frame_align() to the i386 
   architecture vector.  It forces a non-empty correctly aligned dummy 
   frame (thus eliminating the frameless dummy frame problem) (but read the 
   comments that go with the call).

Probably, yes.  The System V ABI says that the stack should be word
aligned.  It doesn't help though, since it only fiddles with the SP.
And on the i386 the frames are already non-empty since the return
address gets pushed on the stack before a function call.

Mark