Re: [PATCH] __builtin_frame_address(0) doesn't work without the frame pointer

[Richard Earnshaw <rearnsha at arm dot com>]

> On Wed, Jul 10, 2002 at 03:56:21PM +0100, Richard Earnshaw wrote:
> > > On Tue, Jul 09, 2002 at 06:11:17PM +0100, Richard Earnshaw wrote:
> > > > ARM certainly does.  But that has special code to copy the return address 
> > > > for frame 0 into a pseudo if the return address is needed.
> > > 
> > > We're talking about __builtin_frame_address, not 
> > > __builtin_return_address.
> > >
> > 
> > Ooops.  Then the ARM is definitely a candidate, since it has a variable 
> > offset between  frame_pointer_rtx and hard_frame_pointer_rtx which depends 
> > on the number of registers that require saving.
> > 
> 
> Yes, ARM seems to be a subject...  BTW, why it was choosed for ARM
> such a stack layout, that the soft frame pointer points into the
> middle of what usually the stack frame is?

GCC's model of the frame pointer points to the bottom of the stack after 
the registers have been pushed, but before the stack is adjusted for local 
variables.  The ARM APCS model of the frame pointer points to the top of 
the saved register area (this is normally four less than the stack-pointer 
address at the point when control reaches the called function).  The 
reason for doing this is that it makes the return sequences significantly 
simpler, often a single instruction.  Of course, the difference between 
these two models of "frame pointer" isn't known until the number of 
registers that need saving is known.  Hence the variable offset.  It was 
because of all this that I added the HARD_FRAME_POINTER code to GCC back 
in 1993.

>  Or it is just an artifical
> thing used for RTL?  It seems, that for ARM the hard FP plays the same
> role, as the soft one for, say, Spark64 - it points for the "real"
> stack frame?  Is it right?

Sorry, I don't know anything about the way the Sparc code does it.

R.