wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

[Jonathan Wilson]

Anyone wanna tell me where in this elephantine codebase to begin looking?

Info on how TLS works in win32 is here:
http://www.winehq.org/hypermail/wine-devel/2003/08/0338.html

I basicly want pointers at the right bits of code...
Course, if someone wants to help me implement this, that would be good also :)

Re: wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

[Richard Henderson]

On Fri, Oct 10, 2003 at 09:02:16PM +0800, Jonathan Wilson wrote:
> Info on how TLS works in win32 is here:
> http://www.winehq.org/hypermail/wine-devel/2003/08/0338.html

I had a very hard time following this.

The absolute first thing you need to do is modify binutils to
be able to handle this.  Once you do that, you can show me the
assembly code you'd write for accessing tls variables both in
the main executable and dllimported from a dll (if that's even
possible).

Once you do that, I can show you the parts of the x86 backend
that need changing.


r~

Re: wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

[Jonathan Wilson]

just posted patch for binutils support of TLS to binutils list.

Anyway, the gist of what GCC needs to do:
1.anytime it sees a variable marked with __declspec(thread) it should mark 
it as "thread local" somehow
2.all variable marked "thread local" need to go into a segment called .tls$ 
instead of wherver else they would go
3.when the variable is accessed, the folowing must be output: (or something 
similar)
mov eax, ds:__tls_index
mov ecx, dword ptr fs:__tls_array
mov edx, edx, [ecx+eax*4]
then you do something like:
mov ds:_x[edx], 0 (in this case it sets it to 0)

Thats what it looks like in the obj file.
__tis_index and __tls_array should be marked external (they come from the 
tlssup.c and atlssup.s respectivly, see my post to the binutils list for 
details)
if the variable is local to this file, it should be defined as a SEGEF that 
points to the .tls$ segment.
if the variable is in another file, the same ASM as above is used but it 
points to an extern not a SEGDEF.

BTW, you cant access a variable thats Thread Local across DLL boundries.

Would like to get all of this stuff into GCC, Binutils and MingW-Runtime 
for the next release of each (in particular, I want to get it into GCC 3.4 
because if I miss the boat, GCC 3.5 is a very long way off)

Re: wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

[Jonathan Wilson]

BTW, .dlls use the same assembler for TLS as .exe files do (near as I can tell)

Re: wanting to implement Thread Local Storage on windows and am looking for pointers into the GCC codebase

[Richard Henderson]

On Wed, Oct 15, 2003 at 08:16:58PM +0800, Jonathan Wilson wrote:
> Anyway, the gist of what GCC needs to do:
> 1.anytime it sees a variable marked with __declspec(thread) it should mark 
> it as "thread local" somehow

This is actually the hardest part.  I'm not quite sure how to make
this happen, and get all the correct checks enabled.  For the moment,
let's ignore this and use the existing syntax:

	__thread int foo;

we can come back to it after everything else works.

> 2.all variable marked "thread local" need to go into a segment called .tls$ 
> instead of wherver else they would go

This happens with the TARGET_ASM_SELECT_SECTION target hook.  
You'll need to write a new one to handle this.  You'll know
to put a variable in the .tls section when 

  if (decl && TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL (decl))

> 3.when the variable is accessed, the folowing must be output: (or something 
> similar)
> mov eax, ds:__tls_index
> mov ecx, dword ptr fs:__tls_array
> mov edx, edx, [ecx+eax*4]
> then you do something like:
> mov ds:_x[edx], 0 (in this case it sets it to 0)

Things to do:

(1) Add a new enum tls_dialect entry.
(2) Add new code to legitimize_tls_address to handle your case.

    I suggest that the computation of edx above be represented
    during early compilation as generated by get_thread_pointer:

	   (unspec:SI [(const_int 0)] UNSPEC_TP)

    This allows good optimization so that we don't have to 
    recompute the value.  Later we can add a post-reload splitter
    to make this schedule a bit better.

I guess that's it.


r~