TLS interception in MSAN?

[olologin]

Hi guys, MSAN is reporting false-positive with latest build of clang-14 (and with clang-12).
Is it because some interceptor implementation is missing? Unfortunately I cannot simplify sources to reproduce it right now, but I think it might be some obvious problem.
I also tested it in valgrind but everything is fine with this code. If it is not enough data for report - you can close this issue, I will reopen it as soon as obtain small reproducible source, maybe I will also be able to help with fix for this (if needed).
Of course libc++ is instrumented on my side.

  Uninitialized value was created by a heap allocation
    #0 0x7c5d60 in malloc (/build/build/Binaries/build/foobar+0x7c5d60) (BuildId: 38e75ad350fd3fa2f9ae977290adb9fd94eeade6)
    #1 0x7f58129e08b7 in allocate_dtv_entry /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:582:19
    #2 0x7f58129e08b7 in allocate_and_init /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:607:31
    #3 0x7f58129e08b7 in tls_get_addr_tail /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:787:31

[olologin]

Right, turns out it was covered by already existing test:
https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/msan/dtls_test.c

OS is debian buster, glibc is 2.28
Also tried on debian bullseye, same result.

root@b30e30645388:/build/build# clang-14 -fPIC -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer -g dtls_test.c -o main
root@b30e30645388:/build/build# clang-14 -fPIC -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer -g dtls_test.c -DBUILD_SO -o main-so.so -shared
root@b30e30645388:/build/build# ./main
==24099==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4a50a1 in Thread1 /build/build/dtls_test.c:33:7
    #1 0x7fc496fd2fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486:8
    #2 0x7fc496d574ce in __clone /build/glibc-vjB4T1/glibc-2.28/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  Uninitialized value was created by a heap allocation
    #0 0x4537e0 in __interceptor_malloc (/build/build/main+0x4537e0) (BuildId: c53a116747654387bfa98d19a266e2b2ba84a1a2)
    #1 0x7fc4970088b7 in allocate_dtv_entry /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:582:19
    #2 0x7fc4970088b7 in allocate_and_init /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:607:31
    #3 0x7fc4970088b7 in tls_get_addr_tail /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:787:31

SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/build/dtls_test.c:33:7 in Thread1
Exiting
root@b30e30645388:/build/build# ldd ./main
        linux-vdso.so.1 (0x00007ffec9d19000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f41f9e10000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f41f9e06000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f41f9c83000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f41f9c7e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f41f9c64000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f41f9aa3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f41f9e3c000)

I think none of those dependencies in lld output have to be instrumented, right?

[dvyukov]

FWIW I recently found that DTLS support in sanitizers is broken:
https://bugs.chromium.org/p/chromium/issues/detail?id=1275223#c15