Fwd: frame_id question

[Jim Blandy <jimb at red-bean dot com>]

---------- Forwarded message ----------
From: Jim Blandy <jimb@red-bean.com>
Date: Nov 11, 2005 9:43 AM
Subject: Re: frame_id question
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Jim Blandy <jimb@redhat.com>, gdb@sources.redhat.com

On 11/11/05, Vladimir Prus <ghost@cs.msu.su> wrote:
>  Do I understand correctly that this can happen only on architectures where
> return address is not automatically pushed to the stack, but moved to a
> special register? Like MIPS's "jal" instructions that moves return address to
> $31

 Yes, that's right.


> Does it mean that for architectures with automatic pushing of return address,
> using '0' as code address in frame_id will be safe? Or there are some corner
> cases?

 I think this is true.  It used to be that some architectures used the
top of the stack as the frame ID's stack address (even though this is
wrong: a call to alloca could change the sp, or the code itself could
push and pop things for its own reasons; either would produce a "new"
frame ID when no call, return, or longjmp has taken place).  On these
architectures, I think you could run into problems.

 But the modern thing to do is to use the base of the stack frame ---
the top of the stack upon entry to the function, or some fixed offset
from that --- as the frame ID's stack address.  When you have Dwarf
CFI for the function, we use the Dwarf CFA for the frame ID stack
address, which meets those qualifications.  I'm not sure what the code
address would be needed for in those architectures.

 If you're porting to a new architecture, you'll want to go through
the test suite results very carefully to look for stack unwinding
problems.