[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