This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add soft frame pointer pseudo on ppc{32,64} and prepare for (optional) FRAME_GROWS_DOWNWARD
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, etoh at jp dot ibm dot com, arjanv at redhat dot com, drepper at redhat dot com
- Date: Mon, 27 Jun 2005 11:35:31 -0400
- Subject: Re: [PATCH] Add soft frame pointer pseudo on ppc{32,64} and prepare for (optional) FRAME_GROWS_DOWNWARD
- References: <20050624224155.GN22349@devserv.devel.redhat.com> <20050626232337.GF26614@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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