bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/27897] New: gold generates wrong TLS relocation for IE access


From: luobodi at hotmail dot com
Subject: [Bug gold/27897] New: gold generates wrong TLS relocation for IE access model
Date: Fri, 21 May 2021 17:33:35 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=27897

            Bug ID: 27897
           Summary: gold generates wrong TLS relocation for IE access
                    model
           Product: binutils
           Version: 2.36
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: luobodi at hotmail dot com
                CC: ian at airs dot com
  Target Milestone: ---

Test code (I'm using GCC 11.1 with binutils 2.36):

```cpp
static thread_local int value1
    __attribute__((tls_model("global-dynamic"))) = 10;

int Get1() { return value1; }

static thread_local int value2
    __attribute__((tls_model("initial-exec")));

int Get2() { return value2; }
```

When compiled with `g++ something.cc -std=c++2a -fPIC -shared -o something.so
-fuse-ld=gold -save-temps`, `readelf -a --wide something.so |grep value2` shows
a relocation of type `R_X86_64_DTPMOD64` for `value2`.

Since `value2` is annotated as `initial-exec`, I would expected an
`R_X86_64_TPOFF64` be emitted instead.

Further investigation suggests that gold is somehow confused by
`_ZL6value1@tlsgd(%rip)` generated by GCC (for accessing `value`). 

If I either:

- Remove `value1` from the source (there won't be `value1@tlsgd` then), or
- Specify `initial-exec` on `value1` (hence avoid `value1@tlsgd`), or
- Manually replace `tlsgd` with `tlsld` in `something.so-something.s` (produced
by `-save-temps`)

gold can emit an `R_X86_64_TPOFF64` for `value2` correctly.

`something.so-something.s` is attached below if it helps:

```asm
        .file   "something.cc"
        .text
        .section        .tdata,"awT",@progbits
        .align 4
        .type   _ZL6value1, @object
        .size   _ZL6value1, 4
_ZL6value1:
        .long   10
        .text
        .globl  _Z4Get1v
        .type   _Z4Get1v, @function
_Z4Get1v:
.LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        data16  leaq    _ZL6value1@tlsgd(%rip), %rdi
        .value  0x6666
        rex64
        call    __tls_get_addr@PLT
        movl    (%rax), %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE0:
        .size   _Z4Get1v, .-_Z4Get1v
        .section        .tbss,"awT",@nobits
        .align 4
        .type   _ZL6value2, @object
        .size   _ZL6value2, 4
_ZL6value2:
        .zero   4
        .text
        .globl  _Z4Get2v
        .type   _Z4Get2v, @function
_Z4Get2v:
.LFB1:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movq    _ZL6value2@gottpoff(%rip), %rax
        movl    %fs:(%rax), %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE1:
        .size   _Z4Get2v, .-_Z4Get2v
        .ident  "GCC: (GNU) 11.1.0"
        .section        .note.GNU-stack,"",@progbits
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]