Re: tls, valgrind gdbserver and qGetTLSAddr

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Wed, 2014-08-06 at 17:17 +0400, Konstantin Serebryany wrote:
> This question rings the bell...
> https://sourceware.org/ml/libc-alpha/2014-04/msg00313.html
> https://sourceware.org/glibc/wiki/ThreadPropertiesAPI

Yes, there are similarities in some of the needs.
There are also some differences, e.g. Valgrind observes
most of what happens by intercepting or wrapping syscalls
or glibc calls (eg pthread creation or dead) and
Valgrind (at least currently) is also not supposed to call any
library to do its work (this is why valgrind cannot use
libthread_db).

On the tls and lsan false positive leak:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/lsan/lit_tests/TestCases/use_tls_dynamic.cc?view=markup&pathrev=200748
I tested this with valgrind.
The block of size 1337 is found reachable,
as the tls block is itself found reachable via a 4K block
mmap-ed by:
 Thread 1: status = VgTs_Runnable
==3515==    at 0x209283: mmap (mmap.S:65)
==3515==    by 0x207CE8: __libc_memalign (dl-minimal.c:79)
==3515==    by 0x203661: _dl_allocate_tls_storage (dl-tls.c:345)
==3515==    by 0x1F450C: init_tls (rtld.c:767)
==3515==    by 0x1F66AE: dl_main (rtld.c:1855)
==3515==    by 0x207616: _dl_sysdep_start (dl-sysdep.c:243)
==3515==    by 0x1F3272: _dl_start (rtld.c:333)
==3515==    by 0x1F2856: ??? (in /lib/ld-2.11.2.so)

Isn't lsan observing the mmap-ed blocks ?
That should be sufficient to avoid the false positive leak ?

Philippe