[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #10 from joseph at codesourcery dot com  2008-12-12 01:25 -------
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote:

> >I suppose that by "32-bit ABI for the x86" you mean a document with
> >1990-1996 SCO copyrights.
> 
> I was going by the linux standards base, which still links to:
>    http://www.caldera.com/developers/devspecs/abi386-4.pdf
> which I believe is still the current official ABI of Linux.
> 
> >This document should be considered of only marginal relevant to current
> >systems; it may have described an ABI for some particular system that is
> >>now obsolete, but is not an accurate description of (for example) the ABI
> >used on IA32 GNU/Linux
> 
> I thought that was precisely what the linux standards base was, and it says
> word (4-byte) alignment of the stack.

LSB is not of much practical relevance to Linux ABIs and is not maintained 
by the people who are actually familiar with those ABIs.  That's apart 
from all the other problems with it as mentioned e.g. at 
<http://udrepper.livejournal.com/8511.html>.

LSB may be a starting point for plausible hypotheses about the ABIs, but 
you need to evaluate it critically to see whether each statement is 
actually an accurate description of fact.  For another example, on 32-bit 
Power Architecture it references a 1995 Sun document - maybe that was 
right for PowerPC Solaris in 1995, but as a member of the Power.org 
working group preparing a document intended to describe the actual current 
ABI I can confidently say the 1995 document is substantially misleading 
regarding the true GNU/Linux ABI in use today.

> >which is a de facto ABI with no written document corresponding precisely.
> 
> This is a link where people mention that fact that gcc is behaving
> non-standardly, so people who want to interoperate with gcc better adopt their
> non-standard behavior.  How do you like it when MS does that?  It seems
> incredibly foolish to me that just because gcc doesn't want to do some trivial
> bit twiddling in the function prologue, you've decided to break the ABI, all so
> that you can lose performance when people need ABI compliance, as well as
> making interoperation much harder for everyone.

I would fully expect that the ABI for working with Windows is that used by 
the present MS compilers and libraries, and if the only ABI documents 
available are 12 years old (I haven't looked) I would consider them of 
limited relevance for determining the current Windows ABI.

The Power.org ABI working group has been going now for two years.  
Producing an accurate current ABI document where one hasn't been 
maintained for over a decade is a lot of work.  If done for IA32 GNU/Linux 
I fully expect it would document that the ABI has 16-byte stack alignment.  
And if some disagreement between code and ABI document were found after 
such a document were written, the fix might well be to change the document 
rather than the code.  Effectively, decisions such as the 16-byte 
alignment one have been made over the years, probably many times, that the 
documentation rather than the code should be changed - and unless and 
until there is a major effect to create a new ABI document, all those 
documentation changes are hidden and queued up and not collected in one 
place.  But each such decision is one that the bug is in the document not 
the code.  And the decision about where the bug lies is not substantially 
influenced by whether the document can in fact be changed or not.

See also Linus's recent comments <http://lkml.org/lkml/2008/12/1/387>.  
The "wrong documentation is irrelevant" applies equally here.  The SCO ABI 
is wrong documentation when Linux in 2008 is concerned, even if it was 
right for SCO Unix in 1996.  If it is the ABI for any system, Linux in 
2008 is not that system, and when looking at it you always need to be 
aware that it describes not the Linux ABI but one with some vague 
similarities to it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496