[Bug c/35271] New: Stack not aligned at mod 16 byte boundary in x86_64 code

[Bug c/35271] New: Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

The stack should be aligned at a 8 mod 16 boundary
at function entry, under both Apple's ABI and under
"System V Application Binary Interface AMD64
Architecture Processor Supplement, draft 0.99".

GCC aligns the stack at a 0 mod 8 boundary.

To quote from the above mentioned document:
  The end of the input argument area shall be aligned
  on a 16 byte boundary.  In other words, the value
  (%rsp - 8) is always a multiple of 16 when control
  is transferred to the function entry point.

How come this hasn't been discovered before (at least I
cannot find any bug reports about it)?  It is because the
x86 is very lax about alignment.  But a few instructions
are not that lax, MOVDQA will trigger a SIGSEGV on *nix
systems.  It is a performance issue for other 16-byte
loads and stores.

I have no test case for this, although it is possible to
trigger in a shared library under darwin, since the runtime
loader used MOVDQA.

Note that this bug has been verified to exist also for
x86_64-*-freebsd, and from reading the compiler sources.
it also affects gnu/linux.


-- 
           Summary: Stack not aligned at mod 16 byte boundary in x86_64 code
           Product: gcc
           Version: 4.2.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tege-gcc at swox dot com
 GCC build triplet: i386-apple-darwin8.11.1
  GCC host triplet: i386-apple-darwin8.11.1
GCC target triplet: i386-apple-darwin8.11.1


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 23:10 -------
Testcase?  Because we do align it for both x86_64-* and i386-darwin.

Now the SVSV i386 ABI says it should be aligned at 4 (word) bytes boundary.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
             Status|UNCONFIRMED                 |WAITING


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #2 from tege-gcc at swox dot com  2008-02-21 13:49 -------
Created an attachment (id=15196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15196&action=view)
Alignment test

This is not a strictly correct test case, it may fail even if
the compiler aligns the stack properly, and it may pass even
if the compiler does not correctly align the stack.  One needs
to read the assembly output to verify that a failure is due to
bad stack alignment.

The idea is to check that two subsequent invocations of foo
places a local variable at the same alignment mod 16.  If the
stack is aligned at 8 mod 16 as it should directly after the
call instruction, any local variable should get the same mod
16 alignment every time.

gcc 4.2.2 as well as gcc 4.2.3 fails this test on both Darwin
and FreeBSD.  The reason is that foo allocates 16 bytes on the
stack, plus the 8 bytes implicitly allocated by call.  This
means the ABI required stack alignment of 16 is not maintained.

$ gcc -O -m64 foo.c  && ./a.out
Abort trap: 6 (core dumped)


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #3 from tege-gcc at swox dot com  2008-02-21 13:53 -------
      Testcase?  Because we do align it for both x86_64-* and i386-darwin.

Well, not as mandated in the 64-bit ABI.

      Now the SVSV i386 ABI says it should be aligned at 4 (word)
      bytes boundary.

This is hardly relevant, since that is a 32-bit ABI.

A test case is difficult to produce, since it is seems hard
to write anything portable.  I made an attempt though, please
see comment attached to it.


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #4 from tege-gcc at swox dot com  2008-02-21 13:57 -------
(From update of attachment 15196)
#include <stdlib.h>

long align;

foo (int flag)
{
  int variable;
  if (flag == 0)
    return (((long)&variable ^ align) & 0xf);
  align = (long)&variable;
  foo (flag - 1);
}

main ()
{
  if (foo (1) != 0)
    abort ();
  exit (0);
}


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #5 from tege-gcc at swox dot com  2008-02-21 14:01 -------
The attachment is not the right file.
I tried to "edit" it but I cannot find out how to do it.
The proper test case is in the comment before this one.
Sorry, I am bugzilla challenged.


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-02-21 15:53 -------
>  int variable;

This variable does not have be aligned 16byte.

>  long long ebi, windowsize, last_windowsize;

Or even these.

The first one is word aligned.  The second one just has to be 8 byte aligned.


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #7 from tege-gcc at swox dot com  2008-02-21 22:01 -------
Sorry, but you ought to read and understand what I write before
you comment, otherwise it becomes rather pointless.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #8 from matz at gcc dot gnu dot org  2008-02-22 23:40 -------
I can confirm this, the code in foo is definitely wrong.  When I compile
the (standard compliant, unlike the example from comment #4) with 4.2 or
4.3 on x86-64, with -O or -O2 it breaks:

% cat foo.c
long align;

int foo (int flag)
{
  int variable;
  if (flag == 0)
    return 42;
  align = (long)&variable;
  return foo (flag - 1);
}

The asm code for foo():
foo:
        subq    $16, %rsp
        testl   %edi, %edi
        movl    $42, %eax
        je      .L4
        leaq    12(%rsp), %rax
        subl    $1, %edi
        movq    %rax, align(%rip)
        call    foo
.L4:
        addq    $16, %rsp
        ret

It's clear that this misaligns the stack for the next calls.  On entry it's
8 mod 16, after the rsp adjustment it's still 8 mod 16, so in front of the
call it's also 8 mod 16, and boom.  Just before calls %rsp needs to be
0 mod 16.

It seems to be important that this is a recursive call.  This body does a
'sub $24', i.e. is correct:

int bar(int);
int foo (int flag)
{
  int variable;
  if (flag == 0)
    return 42;
  align = (long)&variable;
  return bar (flag - 1);
}

The same is true, when I instead add a second call in the body (to bar()),
then the incoming argument is stored in %rbx, which needs saving, so there's
a push, and still a 'sub $16', i.e. again adjusting correctly.


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jh at suse dot cz, matz at
                   |                            |gcc dot gnu dot org
 GCC target triplet|i386-apple-darwin8.11.1     |x86_64


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #9 from matz at gcc dot gnu dot org  2008-02-23 00:40 -------
Mine, have patch.


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
                   |dot org                     |
             Status|WAITING                     |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|2008-02-22 23:41:03         |2008-02-23 00:40:30
               date|                            |


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[hubicka at gcc dot gnu dot org]

------- Comment #10 from hubicka at gcc dot gnu dot org  2008-02-23 12:57 -------
Hi,
as I added to the gcc-patches thread, I think GCC is valid to optimize stack
alignment on the reduced testcase and it is precisely what is supposed to be
done by the code Michael disabled. ABI is not strict about the alignment (or
call convention) requirement for local calls, just for external calls.

It would be good to know the testcase where the misalignment leads to ICE: it
seems that elsewhere we forget to maintain cfun->preferred_stack_boundary when
we are expanding the vector code needing the alignment for real.

Honza


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #11 from matz at gcc dot gnu dot org  2008-02-23 14:08 -------
FWIW, Torbjorn: I agree with Honza that it would be very good to see the
original testcase that segfaults on darwin.  The testcases here are all of
the type where it's questionable if the behaviour is really wrong.

There were indeed also other reports for darwin where the runtime loaders
use of aligned instructions caused problems, but the cause for these problems
was different than what I was patching.  In particular how could the
non-ABI-compliant alignment in 'foo' in these testcase ever lead to a problem
in darwins runtime loader?  We need to see the real testcase, not something
testing something different to give a definitive answer.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #12 from matz at gcc dot gnu dot org  2008-02-23 16:15 -------
In fact I'm now convinced of the opposite, the testcases here don't show any
problem.  The non-alignment of RSP at function entry in these cases is not a
bug.  See the discussions at
  http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01027.html
  http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01028.html

So we really need a different testcase or this PR is INVALID.


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #13 from tege-gcc at swox dot com  2008-02-23 17:09 -------
Created an attachment (id=15214)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15214&action=view)
This is a minimized version of the original faling code.

I understand the reasoning about local calls.  The problem
here is with what *looks* like a local call, the calls to
__gmp_mt_recalc_buffer from __gmp_randget_mt.  But in a shared
library, the Darwin linker will replace these calls with calls
to dyld_stub___gmp_mt_recalc_buffer, and that's where the crash
happens.

One may argue that it is utterly silly to use runtime linker
calls when the function is at a known offset in the same object,
and that this is an Apple tools bug.  I have not read any ABI
document for Darwin, so I will rest my case.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[hubicka at gcc dot gnu dot org]

------- Comment #14 from hubicka at gcc dot gnu dot org  2008-02-23 18:05 -------
I see.  It is quite pity that Darwin's dynamic linker insist on the alignment.
I guess it would be worthwhile to try to tell GCC to optimize those calls as
local: calling overhead of recursive functions is quite expensive.
I will look into this.

Honza


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[hubicka at gcc dot gnu dot org]

------- Comment #15 from hubicka at gcc dot gnu dot org  2008-02-23 18:10 -------
Still, can I ask how does the PLT entry of Darwin look like?  It seems a bit
weird that recursive call that should not trigger lazy binding will get into
code relying on the alignment.
Or are some kind of aliases in place? I guess if the function has aliases we
will need to disable the optimization since it can be called by one name but
recurse to different overwritten name or so.

Honza


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #16 from tege-gcc at swox dot com  2008-02-23 18:27 -------
I don't know how a PLT entry looks like.  They use the object format
macho, of which I know nothing.

Note that the new testcase does not have any recursive calls.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #17 from matz at gcc dot gnu dot org  2008-02-24 19:50 -------
Honza: No recursion is involved here.  I guess (Tege: correct me if I'm wrong)
that already the first call to __gmp_mt_recalc_buffer() from
__gmp_randget_mt() will segfault, as the first call obviously will end up
in the dynamic linker, and that one wants to have $rsp aligned on 8 mod 16.

But I wonder how that could happen.  After all the __gmp_randget_mt function
is global, not local, and can be overridden, so why would GCC assume that
just because it knows its body it can ignore the usual alignment requirements
for global functions?

Is it possible that the darwin support in GCC determines that randget_mt
is a local function (perhaps because MACH-O doesn't allow symbol interposition
like ELF does)?  In that case we can't do this optimization in the darwin
case.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

------- Comment #18 from matz at gcc dot gnu dot org  2008-02-24 19:52 -------
Umm sorry.  I meant the __gmp_mt_recalc_buffer function is global in my last
comment.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

------- Comment #19 from tege-gcc at swox dot com  2008-02-24 20:39 -------
I believe the "local call" optimization is triggered when compiling
__gmp_randget_mt() because its only call is to a function the compiler
determines to be local.  (One can easily untrigger the optimization by
inserting a dummy call to foo() in __gmp_mt_recalc_buffer().)

  After all the [__gmp_mt_recalc_buffer()] function is global, not local,
  and can be overridden, so why would GCC assume that just because it
  knows its body it can ignore the usual alignment requirements for
  global functions?

I think we're using "global" and "local" in two sense here.  Sure,
__gmp_mt_recalc_buffer() is global in visibility, but it is local
to the compilation unit, which is what counts for the semi-invalid
optimization discussed.  GCC bases its decision whether to call with
an unaligned stack solely on the latter definition of "local".


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[jh at suse dot cz]

------- Comment #20 from jh at suse dot cz  2008-02-24 20:49 -------
Subject: Re:  Stack not aligned at mod 16 byte boundary in x86_64 code

Hi,
what about this patch.  There seems to be availablity check missing
earlier in code.  This way GCC will always align calls to functions that
might be overwritten (thus resolved by dynamic linker) with exception of
the recursive calls..

I still wonder how this problem can hit us so late: if we was
misaligning commonly stack on PIC calls and dynamic linker was crashing
on it, I would expect darwin to be unable to boot at all...

Honza

Index: calls.c
===================================================================
--- calls.c     (revision 132575)
+++ calls.c     (working copy)
@@ -2102,7 +2102,9 @@ expand_call (tree exp, rtx target, int i
   if (fndecl)
     {
       struct cgraph_rtl_info *i = cgraph_rtl_info (fndecl);
-      if (i && i->preferred_incoming_stack_boundary)
+      if (i && i->preferred_incoming_stack_boundary
+         && (cgraph_function_body_availability (cgraph_node (fndecl))
+             >= AVAIL_AVAILABLE))
        preferred_stack_boundary = i->preferred_incoming_stack_boundary;
     }



-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2008-02-25 19:15 -------
The real issue is that darwin's back-end says functions that are defined in the
TU are always binds local so they can be called directly.

So I guess a patch to darwin.c is needed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i386-apple-darwin8.11.1     |
   GCC host triplet|i386-apple-darwin8.11.1     |
 GCC target triplet|x86_64                      |x86_64-darwin


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2008-02-25 19:16 -------
This is true even for -fPIC case.  So in this case, the linker and the compiler
are saying two different things even though I do know for PPC darwin this is
always the case.

So maybe in the end this is a bug in the linker and should be reported to Apple
instead.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[hubicka at gcc dot gnu dot org]

------- Comment #23 from hubicka at gcc dot gnu dot org  2008-02-26 09:31 -------
I guess we need
1) Get the patch to check overwritability of body to mainline and branch, since
it is quite wrong to optimize based on knowledge of body that might be replaced
2) Figure out how to get Apple's linker in sync with Darwin backend in GCC.  If
the symbols are locally bound I guess the backend should just output the direct
call, not via PLT table. If the objects are not locally bound we need to change
the predicate.
I am not terribly familiar with MACHOPIC, what is the case?  (ie does MACHOPIC
allow overwritting -fpic symbols like ELF?)


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[jh at suse dot cz]

------- Comment #24 from jh at suse dot cz  2008-02-26 09:43 -------
Subject: Re:  Stack not aligned at mod 16 byte boundary in x86_64 code

> I guess we need
> 1) Get the patch to check overwritability of body to mainline and branch, since
> it is quite wrong to optimize based on knowledge of body that might be replaced
> 2) Figure out how to get Apple's linker in sync with Darwin backend in GCC.  If
> the symbols are locally bound I guess the backend should just output the direct
> call, not via PLT table. If the objects are not locally bound we need to change
> the predicate.
> I am not terribly familiar with MACHOPIC, what is the case?  (ie does MACHOPIC
> allow overwritting -fpic symbols like ELF?)

So in short both fixes are at GCC rather than linker side, assuming that
linker will link direct call to externally visible symbol at link time,
rather than dynamic load time that would be case of ELF?  Can someone
check this?

Honza


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[ubizjak at gmail dot com]

------- Comment #25 from ubizjak at gmail dot com  2008-06-21 15:49 -------
The testcase at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html will
fail for -mfpmath=sse on x86_32.

Related PR is PR 36584.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[hjl dot tools at gmail dot com]

------- Comment #26 from hjl dot tools at gmail dot com  2008-06-21 16:00 -------
I am closing it as an dup for PR 36584. Please reoopen it if it isn't
fixed after

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html

is checked in.

*** This bug has been marked as a duplicate of 36584 ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


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