[Bug c++/104862] New: extern thread_local (emutls) code crashes with ASLR on Windows

[Bug c++/104862] New: extern thread_local (emutls) code crashes with ASLR on Windows

[alvinhochun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862

            Bug ID: 104862
           Summary: extern thread_local (emutls) code crashes with ASLR on
                    Windows
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alvinhochun at gmail dot com
                CC: martin at martin dot st
  Target Milestone: ---

Test code:

/// static_test.cpp

#include <iostream>

thread_local int s1;
extern thread_local int s2;

void dummy(void *a) {
    // no-op
}

void __attribute__ ((noinline)) a(int v) {
    s1 = v;
    dummy(&v);
    s2 = v + 1;
}

int __attribute__ ((noinline)) b() {
    return s1 + s2;
}

int main() {
    int n;
    std::cin >> n;
    a(n);
    std::cout << b();
    return 0;
}

/// static_obj.cpp

thread_local int s2;

/// ----------


Compiled with mingw-builds mingw-w64 gcc
x86_64-11.2.0-release-posix-seh-rt_v9-rev1 [1]:

g++ -Og -g -std=gnu++17 -c static_obj.cpp -o static_obj.o
g++ -Og -g -std=gnu++17 static_test.cpp static_obj.o -o static_test.exe


Running it segfaults:

(gdb) r
Starting program: D:\temp\static_test.exe
[New Thread 5368.0x4568]
[New Thread 5368.0x5598]
[New Thread 5368.0x4aec]
1   # <-- user input

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff663890000 in ?? ()


(gdb) disas a
Dump of assembler code for function _Z1ai:
   0x00007ff6a3891587 <+0>:     push   %rbx
   0x00007ff6a3891588 <+1>:     sub    $0x20,%rsp
   0x00007ff6a389158c <+5>:     mov    %ecx,%ebx
   0x00007ff6a389158e <+7>:     lea    0x1a8b(%rip),%rcx        #
0x7ff6a3893020 <__emutls_v.s1>
   0x00007ff6a3891595 <+14>:    call   0x7ff6a3892730 <__emutls_get_address>
   0x00007ff6a389159a <+19>:    mov    %ebx,(%rax)
   0x00007ff6a389159c <+21>:    add    $0x1,%ebx
   0x00007ff6a389159f <+24>:    lea    -0x400015a6(%rip),%rax        #
0x7ff663890000
   0x00007ff6a38915a6 <+31>:    test   %rax,%rax
   0x00007ff6a38915a9 <+34>:    je     0x7ff6a38915b0 <_Z1ai+41>
   0x00007ff6a38915ab <+36>:    call   0x7ff663890000
   0x00007ff6a38915b0 <+41>:    mov    0x2d99(%rip),%rcx        #
0x7ff6a3894350 <.refptr.__emutls_v.s2>
   0x00007ff6a38915b7 <+48>:    call   0x7ff6a3892730 <__emutls_get_address>
   0x00007ff6a38915bc <+53>:    mov    %ebx,(%rax)
   0x00007ff6a38915be <+55>:    add    $0x20,%rsp
   0x00007ff6a38915c2 <+59>:    pop    %rbx
   0x00007ff6a38915c3 <+60>:    ret
End of assembler dump.


Note the assembler from +24 to +36.

The generated assembler (corresponding to +24 ~ +53):

        leaq    _ZTH2s2(%rip), %rax
        testq   %rax, %rax
        je      .L7
        call    _ZTH2s2
.L7:
        movq    .refptr.__emutls_v.s2(%rip), %rcx
        call    __emutls_get_address
        movl    %ebx, (%rax)


It looks like the symbol _ZTH2s2 is the "thread-local initialization routine
for s2" (which is declared weak) and ends up being null, which is what
`-0x400015a6(%rip)` is supposed to point to. But due to ASLR this address ends
up being offset and causing the jump to not be taken and then calling an
invalid address.

Clang uses `cmpq $0, .refptr._ZTH2s2(%rip)` for this which doesn't have the
same problem.

(Many thanks to Martin Storsjö for helping me on this.)


[1]:
https://github.com/niXman/mingw-builds-binaries/releases/tag/11.2.0-rt_v9-rev1

[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows

[alvinhochun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862

Alvin Wong <alvinhochun at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #1 from Alvin Wong <alvinhochun at gmail dot com> ---
I found from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c25 that there
was a change that seems related to the issue observed in this report. Can
anyone check?

> The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:021ad8e5cf9ab66e1a0a41dce3a54586facb86e0
> 
> commit r12-4036-g021ad8e5cf9ab66e1a0a41dce3a54586facb86e0
> Author: Eric Botcazou <ebotcazou@adacore.com>
> Date:   Fri Oct 1 10:49:34 2021 +0200
> 
>     Fix PR c++/64697 at -O1 or above
>     
>     The BFD fix eliminates the link failure and working code is generated at
>     -O0, but _not_ when optimization is enabled because the optimizer
> changes:
>     
>             movq    .refptr._ZTH1s(%rip), %rax
>             testq   %rax, %rax
>             je      .L2
>             call    _ZTH1s
>     
>     into:
>     
>             leaq    _ZTH1s(%rip), %rax
>             testq   %rax, %rax
>             je      .L2
>             call    _ZTH1s
>     
>     and the leaq now also gets the relocation overflow.  So the fix is to
>     teach legitimate_pic_address_disp_p to reject the transformation when
>     the symbol is an external weak function, which yields:
>     
>             cmpq    $0, .refptr._ZTH1s(%rip)
>             je      .L2
>             call    _ZTH1s
>     
>     and the cmpq keeps a relocation that does not overflow.
>     
>     gcc/
>             PR c++/64697
>             * config/i386/i386.c (legitimate_pic_address_disp_p): For
> PE-COFF do
>             not return true for external weak function symbols in medium
> model.

[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-05-12

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I found from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c25 that
> there was a change that seems related to the issue observed in this report.

Yes, this looks like the same issue, so the fix needs to be extended.

[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Investigating.

[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104862

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |DUPLICATE
   Target Milestone|---                         |11.3

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
It's actually a plain duplicate, so fixed in 11.3 and above.

*** This bug has been marked as a duplicate of bug 64697 ***