public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: TLS on windows
@ 2006-06-04 11:06 Ross Ridge
  2006-06-08 21:59 ` Richard Henderson
  0 siblings, 1 reply; 3+ messages in thread
From: Ross Ridge @ 2006-06-04 11:06 UTC (permalink / raw)
  To: gcc

FX Coudert wrote:
> Now, for an idea of how much work it represents... perhaps someone
>here can tell us?

It's not too hard but it requires changing GCC and binutils, plus a
bit of library support.  In my implementation (more or less finished,
but I have had time to test it yet), I did the following:

	- Used the existing __thread support in the front-end.  Silently
	  ignore the ELF TLS models, because Windows only has one model.
	- Added target specific (cygming) support for __attribute__((thread))
	  aka __declspec(thread) for MSC compatibility.
	- Created an legitimize_win32_tls_address() to replace
	  legitimize_tls_address() in i386.c.  It outputs RTL like:
		(set (reg:SI tp) (mem:SI (unspec [(const_int 44)] WIN32_TIB)))
		(set (reg:SI index) (mem:SI (symbol_ref:SI "__tls_index__")))
		(set (reg:SI base) (mem:SI (add:SI (reg:SI tp)
						   (mult:SI (reg:SI index)
						            (const_int 4)))))
	 	(plus:SI (reg:SI base)
			 (const:SI (unspec:SI [(symbol_ref:SI "foo")]
			                      SECREL))))
	- Handled the WIN32_TIB unspec by outputting "%fs:44" and the
	  SECREL unspec by outputting "foo`SECREL".  I couldn't use
	  "foo@SECREL" because "@" is valid in identifiers with PECOFF.
	- Support .tls sections in PECOFF by creating an
	  i386_pe_select_section() based on the generic ELF version.
	- Added an -mfiber-safe-tls target specific option that makes
	  the references to the WIN32 TIB non-constant.
	- Modified gas to handle "foo`SECREL", based on the ELF support
	  for "@" relocations
	- Fixed some problems with TLS handling in the PECOFF linker
	  script
	- Created an object file that defines the __tls_used structure
 	  (and thus the TLS directory entry) and __tls_index__.

Actually, the last one I haven't done yet.  I've just been using a linker
script to do that, but it should be in a library so the TLS directory
entry isn't created if the executable doesn't use TLS.

					Ross Ridge

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TLS on windows
  2006-06-04 11:06 TLS on windows Ross Ridge
@ 2006-06-08 21:59 ` Richard Henderson
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Henderson @ 2006-06-08 21:59 UTC (permalink / raw)
  To: Ross Ridge; +Cc: gcc

On Sun, Jun 04, 2006 at 07:05:55AM -0400, Ross Ridge wrote:
> FX Coudert wrote:
> > Now, for an idea of how much work it represents... perhaps someone
> >here can tell us?
> 
> It's not too hard but it requires changing GCC and binutils, plus a
> bit of library support.  In my implementation (more or less finished,
> but I have had time to test it yet), I did the following:
> 
> 	- Used the existing __thread support in the front-end.  Silently
> 	  ignore the ELF TLS models, because Windows only has one model.
> 	- Added target specific (cygming) support for __attribute__((thread))
> 	  aka __declspec(thread) for MSC compatibility.
> 	- Created an legitimize_win32_tls_address() to replace
> 	  legitimize_tls_address() in i386.c.  It outputs RTL like:
> 		(set (reg:SI tp) (mem:SI (unspec [(const_int 44)] WIN32_TIB)))
> 		(set (reg:SI index) (mem:SI (symbol_ref:SI "__tls_index__")))
> 		(set (reg:SI base) (mem:SI (add:SI (reg:SI tp)
> 						   (mult:SI (reg:SI index)
> 						            (const_int 4)))))
> 	 	(plus:SI (reg:SI base)
> 			 (const:SI (unspec:SI [(symbol_ref:SI "foo")]
> 			                      SECREL))))
> 	- Handled the WIN32_TIB unspec by outputting "%fs:44" and the
> 	  SECREL unspec by outputting "foo`SECREL".  I couldn't use
> 	  "foo@SECREL" because "@" is valid in identifiers with PECOFF.
> 	- Support .tls sections in PECOFF by creating an
> 	  i386_pe_select_section() based on the generic ELF version.
> 	- Added an -mfiber-safe-tls target specific option that makes
> 	  the references to the WIN32 TIB non-constant.
> 	- Modified gas to handle "foo`SECREL", based on the ELF support
> 	  for "@" relocations
> 	- Fixed some problems with TLS handling in the PECOFF linker
> 	  script
> 	- Created an object file that defines the __tls_used structure
>  	  (and thus the TLS directory entry) and __tls_index__.

Excellent.  Pretty much exactly what I had in mind.

> Actually, the last one I haven't done yet.  I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.

You can also create this in the linker, without a library.
Not too difficult, since you've got to do that to set the
bit in the PE header anyway.


r~

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TLS on windows
@ 2006-06-09  0:24 Ross Ridge
  0 siblings, 0 replies; 3+ messages in thread
From: Ross Ridge @ 2006-06-09  0:24 UTC (permalink / raw)
  To: gcc

Ross Ridge wrote:
> Actually, the last one I haven't done yet.  I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.

Richard Henderson wrote:
> You can also create this in the linker, without a library.
> Not too difficult, since you've got to do that to set the
> bit in the PE header anyway.

Fortunately, the linker already supports setting the TLS directory entry
in the PE header if a symbol named "__tls_used" exists.  Section relative
relocations are also already supported (for DWARF, I think), I just
needed to add the syntax to gas.

					Ross Ridge

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-06-08 23:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-04 11:06 TLS on windows Ross Ridge
2006-06-08 21:59 ` Richard Henderson
2006-06-09  0:24 Ross Ridge

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).