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
"[EMAIL PROTECTED]" 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
