[Bug gas/31092] New: SECREL32 produces wrong value on x86_64-w64-mingw32

[lh_mouse at 126 dot com]

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

            Bug ID: 31092
           Summary: SECREL32 produces wrong value on x86_64-w64-mingw32
           Product: binutils
           Version: 2.41
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

C source:
```
int printf(const char*, ...) __attribute__((__dllimport__));
void exit(int) __attribute__((__noreturn__, __dllimport__));
__thread int my_value = 42;
unsigned int _tls_index;

void
_start(void)
  {
    printf("my_value = %d\n", my_value);
    exit(0);
  }

__attribute__((__section__(".tls"))) char *_tls_start = 0;
__attribute__((__section__(".tls$ZZZ"))) char *_tls_end = 0;

typedef struct _IMAGE_TLS_DIRECTORY64 {
  void* StartAddressOfRawData;
  void* EndAddressOfRawData;
  unsigned int* AddressOfIndex;
  void* AddressOfCallBacks;
  unsigned int SizeOfZeroFill;
  unsigned int Characteristics;
} IMAGE_TLS_DIRECTORY;

__attribute__((used))
const IMAGE_TLS_DIRECTORY _tls_used = {
  &_tls_start, &_tls_end, &_tls_index, 0, 0, 0
};

```

Compile it with Clang to get assembly:  clang test.s -nostdlib -lmsvcrt
-Wl,-e_start
```
        .text
        .def    @feat.00;
        .scl    3;
        .type   0;
        .endef
        .globl  @feat.00
.set @feat.00, 0
        .file   "test.c"
        .def    _start;
        .scl    2;
        .type   32;
        .endef
        .globl  _start                          # -- Begin function _start
        .p2align        4, 0x90
_start:                                 # @_start
.seh_proc _start
# %bb.0:
        subq    $40, %rsp
        .seh_stackalloc 40
        .seh_endprologue
        movl    _tls_index(%rip), %eax
        movq    %gs:88, %rcx
        movq    (%rcx,%rax,8), %rax
        movl    my_value@SECREL32(%rax), %edx
        leaq    .L.str(%rip), %rcx
        callq   *__imp_printf(%rip)
        xorl    %ecx, %ecx
        callq   *__imp_exit(%rip)
        int3
        .seh_endproc
                                        # -- End function
        .section        .tls$,"dw"
        .globl  my_value                        # @my_value
        .p2align        2, 0x0
my_value:
        .long   42                              # 0x2a

        .section        .rdata,"dr"
.L.str:                                 # @.str
        .asciz  "my_value = %d\n"

        .section        .tls,"dw"
        .globl  _tls_start                      # @_tls_start
        .p2align        3, 0x0
_tls_start:
        .quad   0

        .section        .tls$ZZZ,"dw"
        .globl  _tls_end                        # @_tls_end
        .p2align        3, 0x0
_tls_end:
        .quad   0

        .bss
        .globl  _tls_index                      # @_tls_index
        .p2align        2, 0x0
_tls_index:
        .long   0                               # 0x0

        .section        .rdata,"dr"
        .globl  _tls_used                       # @_tls_used
        .p2align        3, 0x0
_tls_used:
        .quad   _tls_start
        .quad   _tls_end
        .quad   _tls_index
        .quad   0
        .long   0                               # 0x0
        .long   0                               # 0x0

        .addrsig
        .addrsig_sym _tls_start
        .addrsig_sym _tls_end
        .addrsig_sym _tls_index
        .addrsig_sym _tls_used
```


This can be assembled with clang and produce:
```
$ clang test.s -nostdlib -lmsvcrt -Wl,-e_start && ./a.exe
my_value = 42

```

but that's not part of the issue. GAS doesn't recognize `.addrsig` so let's
delete them, then try GAS:
```
$ as --version
GNU assembler (GNU Binutils) 2.41.0.20231122
$ as test.s -o test.o && ld test.o -e_start -nostdlib /mingw64/lib/libmsvcrt.a
&& ./a.exe
Segmentation fault
```

Okay let's debug it with x64dbg:

```
00007FF7FC461000 <a. | 48:83EC 28                    | sub     rsp, 0x28
00007FF7FC461004     | 8B05 F63F0000                 | mov     eax, dword ptr
ds:[0x7FF7FC465000]
00007FF7FC46100A     | 6548:8B0C25 58000000          | mov     rcx, qword ptr
gs:[0x58]
00007FF7FC461013     | 48:8B04C1                     | mov     rax, qword ptr
ds:[rcx + rax * 8]
00007FF7FC461017     | 8B90 080046BC                 | mov     edx, dword ptr
ds:[rax - 0x43B9FFF8]
00007FF7FC46101D     | 48:8D0D DC0F0000              | lea     rcx, qword ptr
ds:[0x7FF7FC462000]
00007FF7FC461024     | FF15 1E500000                 | call    qword ptr
ds:[<printf>]
00007FF7FC46102A     | 31C9                          | xor     ecx, ecx
00007FF7FC46102C     | FF15 0E500000                 | call    qword ptr
ds:[<exit>]
00007FF7FC461032     | CC                            | int3
```

We can see that `my_value@SECREL32` becomes `0x43B9FFF8` (`080046BC` in
little-endian order) and that's not correct.


There is another issue: The `@SECREL32` modifier doesn't work in Intel syntax;
it gets treated as part of the symbol name. Maybe this is worth another report.

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