This is the mail archive of the gcc@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: A proposal to align GCC stack


On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
> >and 64 for x86_64. It is the minimum stack boundary. It is fixed.
> 
> Strictly speaking by the above definition it would be 8 for i386.
> The hardware doesn't force the stack to be 32-bit aligned, it just
> performs poorly if it isn't.

We can change the wording.

> 
> >v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary
> >at function entry. If a function is marked with __attribute__
> >((force_align_arg_pointer)) or -mstackrealign option is provided,
> >INCOMING = STACK_BOUNDARY.  Otherwise, INCOMING == MIN(ABI_STACK_BOUNDARY,
> >PREFERRED_STACK_BOUNDARY) because a function can be called via psABI
> >externally or called locally with PREFERRED_STACK_BOUNDARY.
> 
> This section doesn't make sense to me.  The force_align_arg_pointer
> attribute and -mstackrealign assume that the ABI is being
> followed, while the -fpreferred-stack-boundary option effectively

According to Apple engineer who implemented the -mstackrealign,
on MacOS/ia32, psABI is 16byte, but -mstackrealign will assume
4byte, which is STACK_BOUNDARY.

> changes the ABI.  According your defintions, I would think
> that INCOMING should be ABI_STACK_BOUNDARY in the first case,
> and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.

That isn't true since some .o files may not be compiled with
-fpreferred-stack-boundary or with a different value of
-fpreferred-stack-boundary.

> (Or just PREFERRED_STACK_BOUNDARY because a boundary less than the ABI's
> should be rejected during command line processing.)

On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may
want to use 8 byte for PREFERRED_STACK_BOUNDARY.

> 
> >vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required
> >by local variables and calling other function. REQUIRED_STACK_ALIGNMENT
> >== MAX(LOCAL_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY) in case of a
> >non-leaf function. For a leaf function, REQUIRED_STACK_ALIGNMENT ==
> >LOCAL_STACK_BOUNDARY.
> 
> Hmm... I think you should define STACK_BOUNDARY as the minimum
> alignment that ABI requires the stack pointer to keep at all times.
> ABI_STACK_BOUNDARY should be defined as the stack alignment the
> ABI requires at function entry.  In that case a leaf function's
> REQUIRED_STACK_ALIGMENT should be MAX(LOCAL_STACK_BOUNDARY,
> STACK_BOUNDARY).

That is true since if the only local variable is char, LOCAL_STACK_BOUNDARY
will be 1. But we want the stack to be aligned at STACK_BOUNDARY.
We will update our proposal. 

> 
> >Because I386 PIC requires BX as GOT pointer and I386 may use AX, DX
> >and CX as parameter passing registers, there are limited candidates for
> >this proposal to choose. Current proposal suggests EDI, because it won't
> >conflict with i386 PIC or regparm.
> 
> Could you pick a call-clobbered register in cases where one is availale?

Joey, Xuepeng, is that doable?

> 
> >//  Reserve two stack slots and save return address 
> >//  and previous frame pointer into them. By
> >//  pointing new ebp to them, we build a pseudo 
> >//  stack for unwinding
> 
> Hmmm... I don't know much about the DWARF unwind information, but
> couldn't it handle this case without creating the "pseudo frame"?
> Or at least be extended so it could?


Joey, Xuepeng, what do you think?


H.J.


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