[llvm-bugs] [Bug 27174] New: PIE creates incorrect relocations for TLS: R_X86_64_TPOFF32 gets translated to R_X86_64_RELATIVE

[via llvm-bugs]

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

            Bug ID: 27174
           Summary: PIE creates incorrect relocations for TLS:
                    R_X86_64_TPOFF32 gets translated to R_X86_64_RELATIVE
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ed at 80386.nl
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

This bug applies to LLVM trunk (well, r265054 to be exact).

Consider the following made-up program:

_Thread_local int i;
void _start(void) { i = 3; }

If compiled to an object file, it contains the following machine code (x86-64):

$ objdump -d exec.o
Disassembly of section .text._start:
_start:
       0:       55      pushq   %rbp
       1:       48 89 e5        movq    %rsp, %rbp
       4:       64 48 8b 04 25 00 00 00 00      movq    %fs:0, %rax
       d:       c7 80 00 00 00 00 03 00 00 00   movl    $3, (%rax)
      17:       5d      popq    %rbp
      18:       c3      retq

The relocation needed to get this code to work:

$ readelf -r exec.o
Relocation section '.rela.text._start' at offset 0x148 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
00000000000f  000500000017 R_X86_64_TPOFF32  0000000000000000 i + 0

If I now use GNU ld 2.26 (BFD, not Gold) to link this executable with "-pie", I
correctly end up with an executable that does not contain any relocations. The
reason for this is that we're using TLS with a fixed layout of the TLS area.
There is no dynamic TLS.

If I use the latest version of LLD, I see that the following relocation is
generated:

$ readelf -r exec
Relocation section '.rela.dyn' at offset 0x2a0 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
00000000100f  000000000008 R_X86_64_RELATIVE                   
0000000000000000

This is incorrect for two reasons:

- R_X86_64_RELATIVE applies a relocation relative to the base address of the
executable. The location of a TLS variable should not depend on this.
- This relocation points to a location inside of the .text segment, which is
read-only. Applying this relocation at runtime will cause a segmentation fault.

$ readelf -S exec.o
  [ 7] .text             PROGBITS         0000000000001000  00001000
       0000000000000019  0000000000000000  AX       0     0     16

Apart from that, I'd say that LLD is doing a flawless job. Arguably even better
than GNU ld. It generates executables that only depend on R_X86_64_RELATIVE
relocations, which are easier to apply than the R_X86_64_64 relocations that
GNU ld depends on.

-- 
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/20160401/ba8592ca/attachment.html>