[Bug target/80881] Implement Windows native TLS

[Bug target/80881] Implement Windows native TLS

[alexandre.nunes at gmail dot com]

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

Alexandre Pereira Nunes <alexandre.nunes at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexandre.nunes at gmail dot com

--- Comment #18 from Alexandre Pereira Nunes <alexandre.nunes at gmail dot com> ---
I'm working on native TLS for windows targets. The goal is to match clang's
output (the latter has native TLS implemented for quite a while).

[Bug target/80881] Implement Windows native TLS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com]

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

Julian Waters <tanksherman27 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tanksherman27 at gmail dot com

--- Comment #19 from Julian Waters <tanksherman27 at gmail dot com> ---
Jakub, the Windows .tls support to my knowledge only has 1 model. The following
code:

_Thread_local int local = 1;

int get(void) {
    return local;
}

is equivalent to the following (handwritten) assembly:

    .section .tls$, "dw"
    .p2align 2, 0x0
local:
    .long 1
    .text
    .globl get
get:
    movl _tls_index(%rip), %eax
    movq %gs:88, %rcx
    movq (%rcx, %rax, 8), %rax
    movl local@SECREL32(%rax), %eax
    ret

Where rax and rcx can be substituted for any 64 bit scratch register, and
.p2align 2 and .long should be replaced with the appropriate values/directives
depending on the size of the TLS variable (For instance, changing to an 8 byte
long long means .p2align 3 and .quad should be used instead). I am willing to
step up to implement this, but am new to the gcc codebase and am having trouble
finding out how to plug it into the compiler so it can emit the assembly
required for TLS support. You mentioned briefly about how to implement it,
could you run me through the steps required to get the compiler to emit the
assembly above?

Once this is implemented in the compiler, 2 bugs in binutils need to be fixed.
The first is that the assembly fails horribly on the Intel syntax, as gas
cannot recognize @SECREL32 as a directive and instead thinks the entire
local@SECREL32 is a symbol name in Intel mode. The other is that ld linked
executable crashes with a mysterious SIGSEGV on movl local@SECREL32(%rax),
%eax. Nothing is wrong with the assembly, as assembling it with gas and then
linking with clang results in a working exe, instead this is a bug in ld that I
have yet to decipher

Alexandre, how's your progress on Windows TLS going? Could we collaborate to
get this into gcc somehow?

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com]

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

--- Comment #20 from Julian Waters <tanksherman27 at gmail dot com> ---
Could the version for this be bumped to either 14 or 15 too? Thanks

[Bug target/80881] Implement Windows native TLS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |14.1.0, 15.0

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Julian Waters from comment #20)
> Could the version for this be bumped to either 14 or 15 too? Thanks

The version entry just mentions what version the original report was against,
it does not say anything else really. I updated the "known to fail" field to
include 15.0 and 14.1.0 which is the field that says where it does not work
(still).

[Bug target/80881] Implement Windows native TLS

[alexandre.nunes at gmail dot com]

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

--- Comment #22 from Alexandre Pereira Nunes <alexandre.nunes at gmail dot com> ---
(In reply to Julian Waters from comment #19)
> 
> Alexandre, how's your progress on Windows TLS going? Could we collaborate to
> get this into gcc somehow?


Hi Julian,

I used to manage a collection of cross-compiled libraries and tools, including
gcc compiler. I managed to get it to work partially by using this patch as a
origin:
https://github.com/venix1/MinGW-GDC/blob/master/patches/mingw-tls-gcc-4.8.patch

(Perhaps it wasn't exactly this one, but very similar)

It compiled and linked fine with the whole collection of libraries I used to
manage (here: https://build.opensuse.org/project/show/home:polesapart:win64)


From some version on, binutils started to complain about bad relocations in
x86_64 code, I suspect it's correct about this but previous versions didn't
catch it. So I suspect the code generation for x86_64 needs fix, or otherwise
binutils needs a patch to differentiate apart from invalid cases.

Anyway, I'm no longer working on this for quite some time. I'll attach the last
non-published version of the patch I was applying to gcc. I can provide some
help but it was been quite a while so memory is not all bright right now.

When I posted I was trying to write this from scratch (and having a bad time
understanding gcc internals), I even registered as a gcc contributor for this.
But since I found the patch and it seemed to work for my collection (which I
used professionally for 32-bit code at the time), I got lazy.

AFAIK, for that work to be merged to gcc mainstream, you'd have to track the
patch's owner and get it to transfer rights to you or convince him to become a
gcc contributor, if not already. Or rewrite the logic from scratch.

[Bug target/80881] Implement Windows native TLS

[alexandre.nunes at gmail dot com]

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

--- Comment #23 from Alexandre Pereira Nunes <alexandre.nunes at gmail dot com> ---
Created attachment 58642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58642&action=edit
My latest gcc tls support patch

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com]

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

--- Comment #24 from Julian Waters <tanksherman27 at gmail dot com> ---
Thanks for the patch, I've been looking through it these past few days. While
the simpler parts of it I can manage, I'm struggling terribly with
understanding the RTL shifting code in legitimize_tls_address and the RTL
templates in the machine definitions file (i386.md to be specific). Do you
happen to know how to read the RTL code in the patch? I definitely need some
help with figuring out how it works mechanically