On Oct 14, 2005, at 4:43 PM, Kean Johnston wrote:
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
This is the way it is designed. GCC assumes at every entry
point except for main, that the stack has been aligned to 16bytes.
There was a bug in bugzila about this before. And powers (not me)
decided that this was by design and that it is the OS which needs
to make sure that the stack is 16byte aligned even though the
original SYSV ABI does not require this. Since SYSV ABI
does not take into account SSE and it does not even mention them
at all. I had wished that someone would have updated the SYSV ABI
(like they did for altivec) to talk about SSE/SSE2 and how arguments
are passed. Instead GCC just follows what Intel's compiler does
(which is known to have changed).
Almost all other x86 OS's have changed to take the bigger alignment
into account which is why some powers have decided this is by design
that we only change the alignment when invoking main.
I assume you will have the same issues with threads and their stack
alignment.
Maybe it is time to update the SYSV abi for SSE and have SCO
(and other companies) update their OS for the new ABI.
Note: I am not saying that GCC should not be fixed for the case
of main which needs to be fixed at least until everyone agrees
on an ABI which takes SSE into account.
Lucky, x86_64 does not have this trouble.
--------
Here is what the current problem with main, we realign the stack
to 16byte alignment, we call checking function. Then we leave
main (destroying the stack alignment) and then we jump to main1
(this is what is meant by sibling call optimization). The problem
is that we should have jumped directly to main1 but made it a call
which keep the stack aligned correctly.
-- Pinski
