[PATCH v2] Add test case for C++11 thread_local support

[Florian Weimer]

On 10/05/2015 08:37 PM, Florian Weimer wrote:

>> * Testing glibc thread_local destructor support?
>>
>>   If glibc thread_local support is broken, then libstdc++-v3/configure won't
>>   detect __cxa_thread_atexit_impl and libstdc++-v3/libsupc++/atexit_thread.cc
>>   is built with alternate compiler-specific support for destructors. Similarly
>>   if the compiler you're using was built with old-enough glibc to lack that support.
>>
>>   Therefore a pre-requisite of this test is that it must know that the existing
>>   C++ compiler is built to use glibc's __cxa_thread_atexit_impl, otherwise you're
>>   testing libsupc++'s support for thread_local destructors and the test has nothing
>>   to do with glibc?
> 
> Hmm, you are right.  It is actually a libstdc++ matter.  I guess I can
> work around that by interposing __cxxabiv1::__cxa_thread_atexit.  So
> maybe we should run this test twice, once as it is now, and once with
> the interposed symbol.
> 
> Or we can change the fallback implementation of
> __cxxabiv1::__cxa_thread_atexit in libstdc++ to check a weak symbol
> __cxxabiv1::__cxa_thread_atexit_impl first and use that if it is
> available.  Maybe this is useful on its own?

I went with a check on an internal libstdc++ macro.  The test now
remains UNSUPPORTED if the compiler supports it, but libstdc++ has
emuluation only (based on its header file).

I looked at the GCC tests.  Cancellation is already tested.  dlclose,
atexit, and pthread_key_create interactions are not, as far as I can
see.  I don't think we test thread_local access from a thread_local
object destructor, either.

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-test-case-for-C-11-thread_local-support.patch
Type: text/x-patch
Size: 8184 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20151006/79a56e25/attachment.bin>