Just so everyone has a better idea of what I've tried, this is my patch so
far:
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 02e28290441..a2af8325c8f 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -788,6 +788,21 @@ x86_64_elf_select_section (tree decl, int reloc,
return default_elf_select_section (decl, reloc, align);
}
+ATTRIBUTE_UNUSED static section *
+mingw_w64_pe_select_section (tree decl, int reloc,
+ unsigned HOST_WIDE_INT align)
+{
+ if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
+ {
+ if (!DECL_P (decl))
+ decl = NULL_TREE;
+
+ return get_named_section (decl, ".tls$", reloc);
+ }
+ else
+ return default_select_section (decl, reloc, align);
+}
+
/* Select a set of attributes for section NAME based on the properties
of DECL and whether or not RELOC indicates that DECL's initializer
might contain runtime relocations. */
@@ -12151,6 +12166,26 @@ legitimize_tls_address (rtx x, enum tls_model
model, bool for_mov)
machine_mode tp_mode = Pmode;
int type;
+#if TARGET_WIN32_TLS
+ rtx scratch = gen_rtx_SCRATCH (Pmode);
+
+ rtx basereg = gen_reg_rtx (Pmode);
+ rtx thread = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx),
UNSPEC_TP);
+
+ rtx insn = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, gen_rtx_SET
(basereg, thread), gen_rtx_CLOBBER (VOIDmode, scratch)));
+ emit_insn (insn);
+
+ // Only 64-bit is supported
+ rtx offset = gen_rtx_UNSPEC (SImode, gen_rtvec (1, x), UNSPEC_TPOFF);
+ offset = gen_rtx_CONST (SImode, offset);
+
+ rtx reg = gen_reg_rtx (Pmode);
+ insn = gen_rtx_SET (gen_rtx_SUBREG (SImode, reg, 0), offset);
+ emit_insn (insn);
+
+ return gen_rtx_PLUS (Pmode, basereg, reg);
+#endif
+
/* Fall back to global dynamic model if tool chain cannot support local
dynamic. */
if (TARGET_SUN_TLS && !TARGET_64BIT
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index eabb3248ea0..aa88fc50ea0 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -504,6 +504,7 @@ extern unsigned char ix86_prefetch_sse;
#define TARGET_GNU2_TLS (ix86_tls_dialect ==
TLS_DIALECT_GNU2)
#define TARGET_ANY_GNU_TLS (TARGET_GNU_TLS || TARGET_GNU2_TLS)
#define TARGET_SUN_TLS 0
+#define TARGET_WIN32_TLS 0
#ifndef TARGET_64BIT_DEFAULT
#define TARGET_64BIT_DEFAULT 0
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 0a9986c44d4..47c76eb85a2 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -135,3 +135,9 @@ along with GCC; see the file COPYING3. If not see
original mingw32. */
#undef TARGET_LIBC_HAS_FUNCTION
#define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
+
+#undef TARGET_ASM_SELECT_SECTION
+#define TARGET_ASM_SELECT_SECTION mingw_w64_pe_select_section
+
+#undef TARGET_WIN32_TLS
+#define TARGET_WIN32_TLS 1
diff --git a/gcc/config/mingw/winnt.cc b/gcc/config/mingw/winnt.cc
index 803e5f5ec85..5721298b224 100644
--- a/gcc/config/mingw/winnt.cc
+++ b/gcc/config/mingw/winnt.cc
@@ -415,6 +415,8 @@ mingw_pe_unique_section (tree decl, int reloc)
prefix = ".text$";
else if (decl_readonly_section (decl, reloc))
prefix = ".rdata$";
+ else if (DECL_THREAD_LOCAL_P (decl))
+ prefix = ".tls$";
else
prefix = ".data$";
len = strlen (name) + strlen (prefix);
This obviously does not work, and when compiling the simple program on
Windows below:
_Thread_local int local = 2;
int get(void) {
return local;
}
Results in the following error during one of the many RTL passes
# gcc -S -std=c11 -pedantic -Wpedantic tls.c
tls.c: In function 'get':
tls.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 5 2 6 2 (parallel [
(set (reg:DI 100)
(unspec:DI [
(const_int 0 [0])
] UNSPEC_TP))
(clobber (scratch:DI))
]) "tls.c":4:12 -1
(nil))
during RTL pass: vregs
tls.c:5:1: internal compiler error: in extract_insn, at recog.cc:2812
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
I can vaguely see how the RTL resembles the code I wrote in
legitimize_tls_address, but I can't quite tell what is actually wrong with
the erroneous RTL, and probably need help in deciphering this mess, as well
as how to actually emit RTL that properly lowers into the required assembly
best regards,
Julian
On Thu, Aug 8, 2024 at 8:58 PM Julian Waters <tanksherma...@gmail.com>
wrote:
> Hi Claudiu,
>
> Thanks a lot for the clarifications! Unfortunately, though I have looked
> at what you suggested, I still can't quite understand how to emit and work
> with RTL that will ultimately lower into the assembly required for TLS on
> Windows in legitimize_tls_address :( I shall not test your patience and
> bother you any more by bombarding you with repeated questions over and
> over, but once again, thanks for the help!
>
> CC-ing Jan Hubicka, who is an i386 maintainer, which is the platform that
> I aim to implement TLS for an OS for (x86 and x64 Windows) and who's area
> of expertise may help here
>
> best regards,
> Julian
>
> On Wed, Jul 24, 2024 at 4:18 PM Claudiu Zissulescu Ianculescu <
> claz...@gmail.com> wrote:
>
>> Hi Julian,
>>
>> I hope you have Ulrich's document about TLS, if not please google it:
>> "ELF Handling for Thread-Local Storage - Ulrich Drepper"
>>
>> In ARC, I used unspec constructions to emit TLS addresses. If you
>> wanna simplify it, in the legitimzie_tls_address you can only
>> implement the most general case, namely TLS_GLOBAL_DYNAMIC, and all
>> the others to fall back to it. For TLS, you need to reserve a tls
>> register which will hold the tls pointer (in arc is a register holded
>> by arc_tp_regno variable, but in ur case u can fix it).
>> U can use the tls examples in the gcc's dejagnu test folder, compile
>> arc backend and check the output assembly to see how it works.
>> In case of ARC, the global dynamic model generates two relocs:
>>
>> add r0,pcl,@x@tlsgd # R_ARC_TLS_GD_GOT x
>> bl @__tls_get_addr@plt # R_ARC_S21_PCREL_PLT __tls_get_addr
>> # Address of x in r0
>>
>> where __tls_get_addr is a function provided by the OS which will
>> return the address of variable x in r0 (return reg). You should
>> already have the PLT reloc, and you need to implement the TLS_GD_GOT
>> reloc to GOT table. In GOT table you need additionally two relocs:
>> GOT[n] R_ARC_TLS_DTPMOD x
>> GOT[n+1] R_ARC_TLS_DTPOFF x
>>
>> I hope this may clarify it a bit, cheers,
>> Claudiu
>>
>> On Thu, Jul 18, 2024 at 12:43 PM Julian Waters via Gcc <gcc@gcc.gnu.org>
>> wrote:
>> >
>> > I guess I'll just say what platform I want to implement this for, since
>> the
>> > roundabout way of talking about it is probably confusing to everyone.
>> It's
>> > Windows, and hopefully implementing TLS for it should be relatively
>> easier
>> > since there is only 1 TLS model on Windows
>> >
>> > best regards,
>> > Julian
>> >
>> > On Thu, Jul 18, 2024 at 5:39 PM Julian Waters <tanksherma...@gmail.com>
>> > wrote:
>> >
>> > > Hi Claudiu,
>> > >
>> > > Thanks for the tip, I've since looked at and drawn inspiration from
>> > > arc.cc. The main issue I have now is how to implement the code in
>> > > legitimize_tls_address under i386.cc and the corresponding i386.md
>> machine
>> > > description file to get the following assembly for a TLS read
>> (Assuming
>> > > that local is the name of the thread local variable, that the last mov
>> > > depends on the size of the variable, since it would be movq if it was
>> an 8
>> > > byte variable, that rscratch refers to scratch registers, and that
>> > > rscratch1 holds the read TLS value at the end of the operation):
>> > >
>> > > movl _tls_index(%rip), %rscratch1
>> > > movq %gs:88, %rscratch2
>> > > movq (%rscratch2, %rscratch1, 8), %rscratch1
>> > > movl local@SECREL32(%rscratch1), %rscratch1
>> > >
>> > > With some reference from the arc.cc code and another (unofficial)
>> patch
>> > > for the platform that I want to implement TLS for, I've managed a half
>> > > finished implementation of TLS, but the final blocker so to speak is
>> my
>> > > lack of understanding on how the RTL manipulating code in
>> > > legitimize_tls_address works. If you have any pointers on how to
>> manipulate
>> > > RTL to get the assembly required as seen above, I would be very much
>> > > grateful :)
>> > >
>> > > best regards,
>> > > Julian
>> > >
>> > > On Tue, Jul 16, 2024 at 8:16 PM Claudiu Zissulescu Ianculescu <
>> > > claz...@gmail.com> wrote:
>> > >
>> > >> Hi Julian,
>> > >>
>> > >> You can check how we did it for ARC. In a nutshell, you need to
>> define
>> > >> HAVS_AS_TLS macro, you need to legitimize the new TLS address and
>> > >> calls. Please have a look in arc.cc and search for TLS, also use git
>> > >> blame to see the original patches. Of course, there are different
>> ways
>> > >> to implement TLS, in ARC is the simplest solution. Also, u need to
>> > >> hack the assembler, linker and the OS for a full implementation.
>> > >>
>> > >> Cheers,
>> > >> Claudiu
>> > >>
>> > >> On Tue, Jul 9, 2024 at 7:14 PM Julian Waters via Gcc <
>> gcc@gcc.gnu.org>
>> > >> wrote:
>> > >> >
>> > >> > Hi all,
>> > >> >
>> > >> > I'm currently trying to implement Native TLS on a platform that
>> gcc uses
>> > >> > emutls for at the moment, but I can't seem to figure out where and
>> how
>> > >> to
>> > >> > implement it. I have a rough idea of the assembly required for TLS
>> on
>> > >> this
>> > >> > platform, but I don't know where to plug it in to the compiler to
>> make
>> > >> it
>> > >> > work. Could someone point me in the right direction for
>> implementing TLS
>> > >> > for a platform that doesn't have it implemented at the moment?
>> > >> >
>> > >> > I'm aware that I am being vague as to which platform I want to
>> > >> implement it
>> > >> > for. It's a platform that is likely low priority in the eyes of
>> most gcc
>> > >> > maintainers, so I'm deliberately avoiding mentioning what platform
>> it
>> > >> is so
>> > >> > I don't get crickets for a reply :)
>> > >> >
>> > >> > best regards,
>> > >> > Julian
>> > >>
>> > >
>>
>
