Thread Local Storage: .tls segment

[menemenetekel]

Hi,
Again, today, I had hope to simplify access thread local storage using data stored in the .tls segment. Actually, I'm doing all those stuff on base of the MS API methods like TlsAlloc/TlsReAlloc/TlsFree etc. So, I've managed the more complex part of dynamic TLS successfully - fine.
But this seems to me like an overkill for simple static data. I've to manage some static TLS. I try to put them within the .tls segment and the main process thread correctly accesses them - but - all worker threads also access those variables. I conclude, there is no automatism a thread "knows" the section offset of its own variable block. Ok, my second guess is using some segment register doing that. From internet I had some indications fs (for x86) as well as gs (for x64) could hold that info - but again, not automatically. Perhaps, I’ve to load them with the correct offsets? (Honestly, I never ever expected something different - lol)
Does anybody have an idea how it works? For the moment I’m interested in x86 solutions, only.
Many thanks,
Mene

[Rob Neff]

Registeres FS & GS would indeed contain the tls segments you seek ( as well as debug info and exception handling ).  The registers themselves are initialized and maintained by the os for both 32 and 64 bit thus you don't (shouldn't/can't) modify them.

I think you're missing a key concept of tls implementation.  You don't define a .tls section of code, it is created on a per thread basis. Each OS has it's own idea of how tls is handled and that's why you have allocator and accessor functions for manipulating data contained within.  Thus you are correct that, without the supporting framework, a thread doesn't automatically "know" of it's tls without the use of those functions.

[menemenetekel]

Hmm, indeed, you are right. I hoped for a "more simple solution" for simple dump worker threads - but my code was missing the callback methods needed to enable those static TLS mechanism (for compiler and esp. the linker). But then, having to write those callbacks, the effort will be comparable with my existing solution using the TLS API directly... bad luck!

Digging in the PE spec of MS I found the following knock out criterion for .tls solution:
"...Statically declared TLS data objects can be used only in statically loaded image files. This fact makes it unreliable to use static TLS data in a DLL unless you know that the DLL, or anything statically linked with it, will never be loaded dynamically with the LoadLibrary API function..."

... my DLLs will always be loaded by dyn. LoadLibrary calls

Really bad luck but thanks for info.
Mene

[Rob Neff]

IMHO, you should probably just allocate needed memory and store the ptr for each thread.  Voila, instant tls!