[llvm-bugs] [Bug 36326] New: Sanitizers fail to get dynamic TLS sizes properly starting with glibc 2.25

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36326

            Bug ID: 36326
           Summary: Sanitizers fail to get dynamic TLS sizes properly
                    starting with glibc 2.25
           Product: new-bugs
           Version: trunk
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: seurer at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Briefly:  There is a change in glibc 2.25 where memalign is no longer used for
tls allocations which breaks the sanitizers.  I see this on powerpc64 systems
but it will probably affect everyone.

See https://sourceware.org/bugzilla/show_bug.cgi?id=17730


Background details:
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 the test with sanitizer verbosity set to 2 on a 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 an appropriate looking size.


Now if I run it on the system that got updated to fedora 26 which has glibc
2.25 or I build my own glibc 2.25 on the system were it previously worked:

==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


When the code in sanitizer_tls_get_addr.cc can't "guess the glibc version" it
uses 0 for the tls size which is probably what causes all the failures.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180209/95f04f68/attachment.html>