This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add soft frame pointer pseudo on ppc{32,64} and prepare for (optional) FRAME_GROWS_DOWNWARD


On Sun, Jun 26, 2005 at 04:23:37PM -0700, Richard Henderson wrote:
> On Fri, Jun 24, 2005 at 06:41:56PM -0400, Jakub Jelinek wrote:
> > ... the ABI mandated
> > stack layout is kept, all that FRAME_GROWS_DOWNWARD changes
> > is the order of local variables on the stack (and in some
> > cases FRAME_GROWS_DOWNWARD can result in additional 8 bytes
> > of padding, as the variable layout code needs to know
> > alignment before whole size of the frame is known).
> 
> So the ABI mandates that the saved registers are above the local
> stack frame area?  Otherwise I can't think of any reason why you
> couldn't move them lower, which would preclude STARTING_FRAME_OFFSET
> from being a constant.
> 
> I'll have to let an rs6000 maintainer review this patch.

My understanding of the ppc{32,64} stack layout is:
r31=r1+sizeof(alloca area)                    +parent
r1				    	      +r1
+----+--------[+------]+------------+----+----+----+--------+
|save|outgoing[|alloca]|varargs area|vars|regs+save|incoming|
|area|  args  [|area  ]|(sysv4 ABI) |area|area+area|args    |
+----+--------[+------]+------------+----+----+----+--------+
                                              +

Call saved regs are saved in the "regs area" above, which
is above the canary with -fstack-protector (canary is at the
top of "vars area"), before stack_protect_set is executed.
On i386/x86_64 the call saved regs saving area is also above
the canary.

All the patch changes is how the vars area looks like,
with !FRAME_GROWS_DOWNWARD it is populated from bottom up,
and as r1/r31 are supposed to be aligned per ABI, the STARTING_FRAME_OFFSET
macro knows the "save area"+"outgoing args"+"varargs area"
size (and more importantly that sum modulo ABI_STACK_BOUNDARY).
If FRAME_GROWS_DOWNWARD, we need to know the alignment of the top
of vars area (modulo ABI_STACK_BOUNDARY), but it is too early to
know the size of "regs area" at that point, so the patch
mandates that top of "vars area" is ABI_STACK_BOUNDARY aligned.

I guess swapping "regs area" and "vars area" if FRAME_GROWS_DOWNWARD
would work and remove the extra padding sometimes inserted
with -fstack-guard, but I'd prefer if David could comment on that.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]