[llvm-bugs] [Bug 39252] New: [6/7/trunk] -fno-plt generates wrong relocation for std::ios_base::Init leading to segmentation fault

[via llvm-bugs]

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

            Bug ID: 39252
           Summary: [6/7/trunk] -fno-plt generates wrong relocation for
                    std::ios_base::Init leading to segmentation fault
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: romain.geissler at amadeus.com
                CC: llvm-bugs at lists.llvm.org

Hi,

Clang is having some issues with -fno-plt relocation generations leading to
core dumps.

This simple snipped (using libstdc++) will core dump at runtime if built with
-fno-plt:

> cat test.cpp
#include <iostream>

int main(){}

> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/clang++ -fno-plt -o test.exe test.cpp
> ./test.exe
[1]    31050 segmentation fault (core dumped)  ./test.exe

Using "-fplt" works fine.

The issue comes from the code generation for symbols from libstdc++
std::ios_base::Init.

gdb shows this:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000401078 in __cxx_global_var_init ()
(gdb) disas
Dump of assembler code for function __cxx_global_var_init:
   0x0000000000401060 <+0>:     push   %rbp
   0x0000000000401061 <+1>:     mov    %rsp,%rbp
   0x0000000000401064 <+4>:     sub    $0x10,%rsp
   0x0000000000401068 <+8>:     movabs $0x404011,%rdi
   0x0000000000401072 <+18>:    callq  *0x2f78(%rip)        # 0x403ff0
=> 0x0000000000401078 <+24>:    mov    0x2f7c,%rdi
   0x0000000000401080 <+32>:    movabs $0x404011,%rsi       
   0x000000000040108a <+42>:    movabs $0x404008,%rdx
   0x0000000000401094 <+52>:    callq  0x401040 <__cxa_atexit at plt>
   0x0000000000401099 <+57>:    mov    %eax,-0x4(%rbp)
   0x000000000040109c <+60>:    add    $0x10,%rsp
   0x00000000004010a0 <+64>:    pop    %rbp
   0x00000000004010a1 <+65>:    retq   
End of assembler dump.
(gdb) x/a 0x2f7c
0x2f7c: Cannot access memory at address 0x2f7c

If you look at the assembly:
> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/clang++ -fno-plt -o test.S -S test.cpp
> less test.S
...
        subq    $16, %rsp
        movabsq $_ZStL8__ioinit, %rdi
        callq   *_ZNSt8ios_base4InitC1Ev at GOTPCREL(%rip)
        movq    _ZNSt8ios_base4InitD1Ev at GOTPCREL, %rdi
        movabsq $_ZStL8__ioinit, %rsi
        movabsq $__dso_handle, %rdx
...

So the address 0x2f7c was meant to be the address of _ZNSt8ios_base4InitD1Ev at
instruction:
movq    _ZNSt8ios_base4InitD1Ev at GOTPCREL, %rdi

If you check gcc 8 code generation, it is slightly different:
> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/g++ -fno-plt -o test.gcc.S -S test.cpp
> less test.gcc.S
...
        movq    _ZNSt8ios_base4InitD1Ev at GOTPCREL(%rip), %rax
...

So here the key difference is that the relocation is relative to $rip when
generated by gcc (which works) and is not relative to anything when generated
by clang (which does not work), leading to core dumps and wrong behavior.

I have this problem with clang 7, but checking a bit godbolt it seems that
clang 6, clang 7 and clang trunk are all affected by the very same issue.

Cheers,
Romain

-- 
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/20181011/8d96a663/attachment.html>