dlpi_tls_data is incorrect NULL when dlpi_tls_modid>0

[Florian Weimer]

* Fangrui Song:

> I was trying to clean up llvm-project/compiler-rt sanitizers GetTls
> function https://reviews.llvm.org/D98926 and my change was reverted
> due to an annoying Ubuntu 16.04 glibc 2.23 bug (seem so on both amd64
> and ppc64le)
> dlpi_tls_data is incorrect NULL when dlpi_tls_modid>0.
>
> Thread 1 "tls_race.cpp.tm" hit Breakpoint 6,
> __sanitizer::CollectStaticTlsRanges (info=0x7fffffffe8d0, size=64,
> data=0x7fffffffe9d0) at
> /tmp/llvm/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:294
> 294       if (!info->dlpi_tls_data)
> (gdb) p *info
> $5 = {dlpi_addr = 0, dlpi_name = 0x7ffff7ffe6f8 "", dlpi_phdr =
> 0x400040, dlpi_phnum = 10, dlpi_adds = 10, dlpi_subs = 0,
> dlpi_tls_modid = 1, dlpi_tls_data = 0x0}
>
> This works fine on glibc 2.31.

How have you verified this on glibc 2.31?  As far as I can tell, the
TLS block address assignment happens lazily, and dl_iterate_phdr does
not trigger it.  So it could be the result of different TLS access
patterns.