<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 - [x86] LLVM assembles and can even codegen a R_X86_64_GOTTPOFF relocation outside of movq and addq instructions"
href="https://bugs.llvm.org/show_bug.cgi?id=36165">36165</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[x86] LLVM assembles and can even codegen a R_X86_64_GOTTPOFF relocation outside of movq and addq instructions
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</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>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>chandlerc@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, echristo@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Consider the assembly below:
```
shlxit: # @shlxit
.cfi_startproc
# %bb.0: # %entry
pushq %rax
.cfi_def_cfa_offset 16
movl (%rsi), %eax
cmpl %edi, %eax
jl .LBB2_4
# %bb.1: # %if.then
shlxq %rdx, g@GOTTPOFF(%rip), %rdx
movq %fs:(%rdx), %rdx
movq %rdx, (%rcx)
cmpl %edi, %eax
jne .LBB2_2
# %bb.3: # %if.else
callq dummy2
jmp .LBB2_4
.LBB2_2: # %if.then2
callq dummy1
.LBB2_4: # %if.end3
xorl %eax, %eax
popq %rcx
retq
```
LLVM will assemble this without complaint, but the GOTTPOFF relocation here is
bogus. Both LLD and BFD-LD complain:
```
<span class="quote">> ./dev/bin/clang -fuse-ld=lld -march=haswell -fPIE -pie -O2 -o shlx_crash shlx_crash.s shlx_crash.c Tue 30 Jan 2018 07:35:51 PM PST</span >
/home/chandlerc/src/llvm/build/./dev/bin/ld.lld: error: shlx_crash.c:(function
shlxit): R_X86_64_GOTTPOFF must be used in MOVQ or ADDQ instructions only
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
```
```
./dev/bin/clang -march=haswell -fPIE -pie -O2 -o shlx_crash shlx_crash.s
shlx_crash.c
Tue 30 Jan 2018 07:36:49
PM PST
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/shlx_crash-c81319.o: TLS transition from R_X86_64_GOTTPOFF to
R_X86_64_TPOFF32 against `g' at 0x2c in section `.text' failed
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
```
Amazingly, the Gold installed on my system accepts this without complaint.
It would seem good for the LLVM assembler to reject this out right however. We
don't need to get to the linker to notice that we've asked for an invalid
relocation here.
What is much more scary is that LLVM can actually form this relocation. There
is no IR you can feed `llc` today to form it, but we have generic folding logic
for SHLX64rr -> SHLX64rm in the X86 backend. It should be possible to write an
MIR test case (but I don't know MIR very well) which forms a movq with this
relocation and a SHLX64rr of the resulting register and the backend will fold
the load into a memory operand of SHLX64rm.
At least, I have an MI pass that ended up doing something roughly like this and
I observed LLVM generating this bogus relocation (and gold failing to diagnose
it) which resulted in garbage bytes in the executable and SIGILL during
execution.</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>