[llvm-bugs] [Bug 36165] New: [x86] LLVM assembles and can even codegen a R_X86_64_GOTTPOFF relocation outside of movq and addq instructions

[via llvm-bugs]

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

            Bug ID: 36165
           Summary: [x86] LLVM assembles and can even codegen a
                    R_X86_64_GOTTPOFF relocation outside of movq and addq
                    instructions
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: chandlerc at gmail.com
                CC: craig.topper at gmail.com, echristo at gmail.com,
                    llvm-bugs at lists.llvm.org

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 at 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:

```
> ./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
/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.

-- 
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/20180131/f77b0404/attachment-0001.html>