(For those unfamiliar with this mechanism, the 'background' section of this codeproject article provides a quick summary).
When I link my threads library (static library) to an executable, my TLS callback is called as expected. However if I link the threads library in to a DLL (by which I mean, create a DLL which is linked against my static library), the callbacks aren't called.
Furthermore if I go poking around in my MSVC build of the dll (with this, for example) the AddressOfCallBacks field (0x1010DD88) in the PE TLS directory points in to the string table once I've subtracted the preferred image load address (0x10000000). Without the subtraction the address is beyond the end of the image, so it appears to be bogus either way, though realignment at load time might end up shuffling things about suitably(?).
Does anybody know if the PE TLS callback mechanism is supposed to work for DLLs in this manner?
I couldn't find anything on the web that indicated it shouldn't work, but on the other hand all the examples I found were creating executables.
I'm targeting recent versions of MS Visual C++ and MinGW GCC. Here's the code snippet compiled in to my static library that places a pointer to the callback in the appropriate PE section.
extern "C"
{
#if defined(_MSC_VER)
# if defined (_M_IX86)
# pragma comment(linker, "/INCLUDE:__tls_used")
# else
# pragma comment(linker, "/INCLUDE:_tls_used")
# endif
# pragma data_seg(".CRT$XLB")
PIMAGE_TLS_CALLBACK mtl_tls_callback_ = mtl::tls_callback;
# pragma data_seg()
#elif defined(__GNUC__)
PIMAGE_TLS_CALLBACK mtl_tls_callback_ __attribute__ ((section(".CRT$XLB"))) = mtl::tls_callback;
#else
# error "Toolchain not supported 
"
#endif
} // extern "C"
The workaround is to provide an auxhiliary DLL and have its DllMain do the cleanup, but I'd like to know if I can avoid having to do that.
