llvm dev - Feb 2018 - santizer problems with dynamic thread local storage

I updated a powerpc64 be system from fedora 25 (glibc 2.24) to fedora 26 
(glibc 2.25) and several test cases started failing that deal with 
dynamic thread local storage.

Failing Tests (3):
     LeakSanitizer-AddressSanitizer-powerpc64 :: 
TestCases/Linux/use_tls_dynamic.cc
     LeakSanitizer-Standalone-powerpc64 :: 
TestCases/Linux/use_tls_dynamic.cc
     MemorySanitizer-POWERPC64 :: dtls_test.c

I looked at dtls_test.c in detail


******************** TEST 'MemorySanitizer-POWERPC64 :: dtls_test.c' 
FAILED ********************
Script:
--
/home/seurer/llvm/build/llvm-test/./bin/clang  -fsanitize=memory 
-mno-omit-leaf-frame-pointer -fno-omit-frame-pointer 
-fno-optimize-sibling-calls  -m64  -gline-tables-only -g 
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c 
-o 
/home/seurer/llvm/build/llvm-test/projects/compiler-rt/test/msan/POWERPC64/Output/dtls_test.c.tmp
/home/seurer/llvm/build/llvm-test/./bin/clang  -fsanitize=memory 
-mno-omit-leaf-frame-pointer -fno-omit-frame-pointer 
-fno-optimize-sibling-calls  -m64  -gline-tables-only -g 
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c 
-DBUILD_SO -fPIC -o 
/home/seurer/llvm/build/llvm-test/projects/compiler-rt/test/msan/POWERPC64/Output/dtls_test.c.tmp-so.so
-shared
/home/seurer/llvm/build/llvm-test/projects/compiler-rt/test/msan/POWERPC64/Output/dtls_test.c.tmp
2>&1
--
Exit Code: 77

Command Output (stdout):
--
==12029==WARNING: MemorySanitizer: use-of-uninitialized-value
     #0 0x10d636528 in Thread1 
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c:22:7
     #1 0x10d635630 in __msan::MsanThread::ThreadStart() 
/home/seurer/llvm/llvm-test/projects/compiler-rt/lib/msan/msan_thread.cc:77
     #2 0x10d5c07c0 in MsanThreadStartFunc(void*) 
/home/seurer/llvm/llvm-test/projects/compiler-rt/lib/msan/msan_interceptors.cc:1080
     #3 0x7fff819dbf54 in start_thread 
(/lib64/power7/libpthread.so.0+0xbf54)
     #4 0x7fff8172657c in __GI___clone (/lib64/power7/libc.so.6+0x16657c)

SUMMARY: MemorySanitizer: use-of-uninitialized-value 
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c:22:7 
in Thread1
Exiting


If I run it on an older system with glic 2.17 installed and turn on msan 
debug verbosity to 2 I see this:

==100505==__tls_get_addr: DTLS_Resize 0x3fff9e1aebf0 0
==100505==__tls_get_addr: 0x3fff9e4dff38 
{0x000000000003,0xffffffffffff8000} => 0x3fff9d8b0000; tls_beg: 
0x3fff9d8b0000; sp: 0x3fff9e1ad740 num_live_dtls 1
==100505==__tls_get_addr: glibc <=2.18 suspected; 
tls={0x3fff9d8b0000,0x000000100000}
stack: 0x3fff9e1ad950 dtls: 0x3fff9d8b0000
...etc... and the test works OK.

The == messages are from DTLS_on_tls_get_addr in 
sanitizer_tls_get_addr.cc and show that it correctly deduced the glibc 
version and that all worked as expected.


If I run it on a newer system with glibc 2.24 I see this:

==39955==__tls_get_addr: DTLS_Resize 0x7fffaa73ebe0 0
==39955==__tls_get_addr: 0x7fffaaa6ff30 
{0x000000000003,0xffffffffffff8000} => 0x7fffa9e40000; tls_beg: 
0x7fffa9e40000; sp: 0x7fffaa73d6f0 num_live_dtls 1
==39955==__tls_get_addr: glibc <=2.18 suspected; 
tls={0x7fffa9e40000,0x000000100000}

Huh, the debug output is wrong about the glibc version but it does work. 
  the "tls=" line shows it got the same size (0x00000100000) as on the
older system.


Now if I run it on the system that got updated to fedora 26 which has 
glibc 2.25:

==87783==__tls_get_addr: DTLS_Resize 0x7fff810febe0 0
==87783==__tls_get_addr: 0x7fff8142ff30 
{0x000000000003,0xffffffffffff8000} => 0x7fff807f0000; tls_beg: 
0x7fff807f0000; sp: 0x7fff810fd6d0 num_live_dtls 1
==87783==__tls_get_addr: Can't guess glibc version


Looking at the code in sanitizer_tls_get_addr.cc when it can't "guess 
the glibc version" it uses 0 for the tls size which is probably what 
causes all the failures.  I looked in detail at all of the code in 
sanitizer_tls_get_addr.cc and none of the choices where it is trying to 
figure out the size will work on this system.

So is there some other way to figure out the tls size here?  has anyone 
seen a similar problem with more recent versions of glibc on 
non-powerpc64 systems?
-- 

-Bill Seurer