[llvm-bugs] [Bug 26779] New: Stack misaligned calling global constructor of library compiled with gcc 4.8.2

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26779

            Bug ID: 26779
           Summary: Stack misaligned calling global constructor of library
                    compiled with gcc 4.8.2
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: f14_tomcat1 at hotmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 15961
  --> https://llvm.org/bugs/attachment.cgi?id=15961&action=edit
Crash repro

I have a library compiled with gcc 4.8.2 which statically initialises an array
using movaps. The movaps instruction is generated by gcc at optimization level
3.

When the library is loaded from a clang compiled application, I get a seg fault
on the movaps instruction. The pointer movaps is trying to write to is not
aligned to 16 bytes.

If I recompile the clang application with -mstackrealign, it works. It looks
like clang does not ensure the stack is aligned before calling
__global_ctx_aux.



A simple repro is attached. Here's the relevant call stack for the repro:

#0  0x00007ffff7dfc6de in _GLOBAL__sub_I_Mat4.cpp () from
./libClangCrashRepro.so
#1  0x00007ffff7dfc736 in __do_global_ctors_aux () from ./libClangCrashRepro.so
#2  0x00007ffff7dfc54b in _init () from ./libClangCrashRepro.so
#3  0x00007ffff78bb000 in ?? ()
#4  0x0000003e7260e605 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#5  0x0000003e72600b3a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffca93 in ?? ()
#8  0x0000000000000000 in ?? ()


Dump of assembler code for function _GLOBAL__sub_I_Mat4.cpp:
   0x00007ffff7dfc6c0 <+0>:    mov    0x200319(%rip),%rax        #
0x7ffff7ffc9e0
   0x00007ffff7dfc6c7 <+7>:    cmpb   $0x0,(%rax)
   0x00007ffff7dfc6ca <+10>:    jne    0x7ffff7dfc702
<_GLOBAL__sub_I_Mat4.cpp+66>
   0x00007ffff7dfc6cc <+12>:    movb   $0x1,(%rax)
   0x00007ffff7dfc6cf <+15>:    mov    0x20033a(%rip),%rax        #
0x7ffff7ffca10
   0x00007ffff7dfc6d6 <+22>:    movss  0x82(%rip),%xmm0        # 0x7ffff7dfc760
=> 0x00007ffff7dfc6de <+30>:    movaps %xmm0,(%rax)
   0x00007ffff7dfc6e1 <+33>:    movaps 0x88(%rip),%xmm0        # 0x7ffff7dfc770
   0x00007ffff7dfc6e8 <+40>:    movaps %xmm0,0x10(%rax)
   0x00007ffff7dfc6ec <+44>:    movaps 0x8d(%rip),%xmm0        # 0x7ffff7dfc780
   0x00007ffff7dfc6f3 <+51>:    movaps %xmm0,0x20(%rax)
   0x00007ffff7dfc6f7 <+55>:    movaps 0x92(%rip),%xmm0        # 0x7ffff7dfc790
   0x00007ffff7dfc6fe <+62>:    movaps %xmm0,0x30(%rax)
   0x00007ffff7dfc702 <+66>:    repz retq 

The highlighted movaps line corresponds to Mat4.h:13. The value of xmm0 is
{1,0,0,0} as expected, and rax is 6294696 which is not on a 16 byte boundary.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160301/0a122409/attachment.html>