Re: [boost] Windows MSVC thread exit handler for staticly linked Boost.Thread

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-08-04 03:19:17

Roland wrote:
> On Wed, 04 Aug 2004 08:56:51 +0200 Bronek Kozicki <brok_at_[hidden]> wrote:
>>We are not. But Holger Grund proposed solution that worked on MSVC6 (at 
>>least on Windows Server 2003), and  that solution was just defining 
>>symbol _tls_used instead of asking compiler to create it. EXE did not 
>>contain .tls section at all in this case.
> 
> I am a little afraid, that defining _tls_used ourselfes, we could messs up with the
> copilers ability to handle __declspec(thread) correctly. Did you any testing on
> this so far?

To clarify the situation from my perspective:

The PECOFF spec simply says that (on x86) _tls_used will be defined if
static TLS is being used.  What it doesn't say is that _tls_used is
actually the TLS directory itself.  The system is set up so that
absolutely no special linker magic is needed for static TLS, with the
sole exception that if the linker notices the _tls_used symbol, it will
cause the TLS directory pointer to refer to it.

_tls_used is an object of the TLS directory type, usually defined in
.rdata.  On Microsoft implementations, it is provided by tlssup.obj
within the runtime library, which uses normal features of linkers and PE
to arrange for the TLS directory to contain the necessary pointers.
tlssup.obj also provides a few other external TLS symbols.

The MSVC6 problem is that theres a trivial bug in tlssup.obj.  (Roland
also mentions a linker problem, but I have been unable to reproduce this
myself.)  If you duplicate the symbols in tlssup.obj exactly, with the
exception of the bug fix, it makes everything work perfectly.  (If the
duplication is not exact, it will break __declspec(thread), cause link
time errors, or other unexpected things.)

In summary, duplicating tlssup.obj (which is trivial, especially because
the Microsoft tlssup.obj has debugging information) and providing the
bug fix for MSVC6 forms an alternate solution to the MSVC6 problem,
opposed to Roland's runtime fixup.

I have no particular technical preference either way; neither solution
is particularly clean, but neither seems particularly harmful if done right.

Aaron W. LaFramboise