[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Apr 5 03:36:07 UTC 2021


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774

--- Comment #4 from maskray <emacsray at gmail.com> ---
I want to use dlpi_tls_data for static TLS blocks (from the main executable and
initially loaded shared objects).
Working dynamic TLS blocks will be nice to have for consistency.

I will try calling __tls_get_addr({tls_modid,0}) as a workaround, but it
probably forces allocation (at least in glibc; I guess FreeBSD rtld/libc may be
similar) so slightly inferior (but not matters for most not-too-size-concerned
applications).

If you are interested, there is a complex story behind "why does sanitizer
runtime need to know static/dynamic TLS blocks".
In the end I think we may need libc APIs. Once I know the context sufficiently
well, I shall start a discussion on https://www.openwall.com/lists/libc-coord

Currently I have written down some notes in
https://maskray.me/blog/2021-02-14-all-about-thread-local-storage#why-does-compiler-rt-need-to-know-tls-blocks
Precise static TLS blocks tracking is more important than precise dynamic TLS
blocks.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list