On Sun, Jun 04, 2006 at 02:03:05PM +0200, Piotr Wyderski wrote:
> fs:[0x14] is a per-thread 32-bit word available for applications,
> so you can store a pointer to your own TLS array there.
I don't think we can hijack this.
> fs:[0x2c] points to a Windows-specific TLS array, so you can
> make use of it, too, but you must conform to the limitations of
> the WinAPI constraints related with TLS management.
Given that microsoft's openmp implementation is also limited
in this way, I don't think that's a real problem.
> >Now, for an idea of how much work it represents... perhaps someone
> >here can tell us?
The biggest piece of work is in the linker, noticing the
existance of the .tls section and setting up the IMAGE_TLS_DIRECTORY
structure, and related activities. There's a value I'll name
"tls_handle" that is created as part of this; ideally that would
use whatever name vc++ does in its object files. There's also
arranging for tls symbol references to resolve to the offset of
the symbol in the .tls section, rather than some sort of absolute
address.
On the compiler side, you'd need to replace legitimize_tls_address
with a windows implementation. You'd need some new patterns, since
you'll be wanting to generate something akin to
movl %fs:0x2c, %eax // global array base
movl tls_handle, %edx // value from TlsAlloc
movl (%eax, %edx, 4), %eax // local array base
addl $variable, %eax // compute address
movl variable(%eax), %ecx // when loading/storing a value
r~
