<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [6/7/trunk] -fno-plt generates wrong relocation for std::ios_base::Init leading to segmentation fault"
href="https://bugs.llvm.org/show_bug.cgi?id=39252">39252</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[6/7/trunk] -fno-plt generates wrong relocation for std::ios_base::Init leading to segmentation fault
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>romain.geissler@amadeus.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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:
<span class="quote">> cat test.cpp</span >
#include <iostream>
int main(){}
<span class="quote">> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/clang++ -fno-plt -o test.exe test.cpp
> ./test.exe</span >
[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@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:
<span class="quote">> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/clang++ -fno-plt -o test.S -S test.cpp
> less test.S</span >
...
subq $16, %rsp
movabsq $_ZStL8__ioinit, %rdi
callq *_ZNSt8ios_base4InitC1Ev@GOTPCREL(%rip)
movq _ZNSt8ios_base4InitD1Ev@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@GOTPCREL, %rdi
If you check gcc 8 code generation, it is slightly different:
<span class="quote">> /opt/1A/toolchain/x86_64-2.6.32-v4/bin/g++ -fno-plt -o test.gcc.S -S test.cpp
> less test.gcc.S</span >
...
movq _ZNSt8ios_base4InitD1Ev@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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>