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
> >>
> >
