This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: continuing egcs-1.1 problems
- To: dje at watson dot ibm dot com (David Edelsohn)
- Subject: Re: continuing egcs-1.1 problems
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Thu, 12 Nov 1998 01:38:04 +0000 (GMT)
- Cc: gdt at linuxppc dot org, egcs-bugs at cygnus dot com, egcs at cygnus dot com, bacon at mediaone dot net, phadke at kewalo dot eng dot hawaii dot edu, ehl at funghi dot com, Franz dot Sirl-kernel at lauterbach dot com, bacon at aerodyne dot com, meissner at cygnus dot com, law at cygnus dot com
> >>>>> Gary Thomas writes:
>
> Gary> How is it possible that the stack remain 16 byte aligned when an object
> Gary> (the trampoline code) of only 40 bytes is being created [on the stack]?
>
> While a 40 byte object may be created on the stack, the next
> allocation of an object that must be aligned, like a new stack frame, will
> round up the address to the stack alignment boundary.
If you don't define your own special way to allocate a trampoline, the
trampoline will be allocated very much like a structure-typed variable
on the stack, i.e. it is part of the stack frame of the caller, which
gets allocated as a single chunk.
The only thing special about trampolines is that the alignment is not
done when the trampoline is allocated in the stack frame; if you need
alignment, you have to define TRAMPOLINE_ALIGNMENT, and a bit more space
will be reserved in the stack frame, and the alignment will be done at run
time.
That allows to have a stricter alignment for the trampoline than for the
stack, but it wastes some space because it doesn't take the known alignment
of the stack into account.