Initial stack frame

[Jerry Van Baren]

At 03:46 PM 1/30/01 +0100, Wolfgang Denk wrote:

>In message <4.3.2.20010130074919.00bb0a80 at falcon.si.com>
>Jerry Van Baren wrote:
> >
> > One of the differences between the ABI and EABI is that the EABI
> > requires 8 byte alignment of the stack and the ABI requires 16 byte
> > alignment (EABI, p.28).
>
>Yes, ok. But what is implemented by GCC and glibc? The SVR4 ABI or
>the EABI?
>
>In other words: Wolfgang Grandegger wants to know if  we  must  align
>"private" stack frames on 8 or 16 byte boundaries...
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
>Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
>(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
>auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

The stack frame alignment shouldn't matter as long as it doesn't matter
to the processor (there may be efficiency reasons to align to 16 bytes,
but there doesn't appear to be any operational problems aligning to 8
bytes -- I never knowingly misaligned to 4 bytes so I don't know if
that works).

The difference between 8 and 16 byte alignment is extra padding words
inside the stack frame.  Since C doesn't allow you to access a
function's variables from within a nested function (Pascal is the only
language I can think of that does this), nobody but the local function
should need to know where the variables are inside a given stack
frame.  Since that is the routine that put in the padding, it would
know where the the registers and variables are.  Well, on second
thought, the debugger (gdb) needs to know where the padding is in order
to display variables and parameters of the function, but that is
getting pretty deep into the system.  Stack back-tracing should use the
frame back chain, which is independent of the alignment padding.

The ABI/EABI doesn't specify where the padding should be put in the
frame, but it would logically go in the "Area for constructing
parameter lists for callees" portion of the frame.  The simplest thing
to do would be to compile some example functions and look at the
disassembled output, and then do the same thing -- my favorite method
of programming (plagiarism is a Good Thing in programming :-).

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/