"Aaron W. LaFramboise" wrote:
As a last resort, the TLS directory (that pesky _tls_used symbol) can be redefined, but this is hackish, and on the edge of what I'd consider acceptable, and would need to be tested quite extensively to make sure it is compatible. For example, the suggestions so far for overriding the TLS directory will break __declspec(thread) and will probably cause random redefined symbol link failures in some situations.
Here are some (hopefully) more specific details about problems with the static library, using VC++ 7.1, Debug compilation, linking with static multithreaded CRT. 1) The main program code does not really matter - in my case it is a dumb Win32 console exe that uses no boost code, has no extra threads (except for the main process thread) and its sole purpose is to call foo() function in a static library and exit. 2) Beside implementing foo() fuction called from the main, static library uses no boost code and the only requirement is to get: void NTAPI tls_callback (PVOID, DWORD Reason, PVOID) { ... whatever, some code where you can set a breakpoint } invoked when the main program thread exits. So far I found only two ways to hit the breakpoint set in tls_callback: A) Put this code in static library: extern "C" int _tls_used; int dummy() { return _tls_used; } OR B) put this: __declspec(thread) int ithread; You don't have to create a thread, use ithread variable or do anything else in your static library code except for implementing foo() and tls_callback(). Either A or B will cause tls_callback to be called (breakpoint will be hit) with VC++ 7.1, but only and only if the following is also a part of the static library code: #pragma data_seg(push, old_seg) #pragma data_seg(".CRT$XLB") DWORD tls_callback_ptr = (DWORD)tls_callback; #pragma data_seg(pop, old_seg) So, unless I made some gross mistake, it seems to me it is quite lame that Microsoft would document TLS callbacks PEF data but not provide any documented way to define and declare TLS callbacks. Tony