This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TLSDESC clobber ABI stability/futureproofness?
On Oct 11, 2018, Rich Felker <dalias@libc.org> wrote:
> However the only way to omit this path from TLSDESC is
> installing the new TLS to all live threads at dlopen time
Well, one could just as easily drop dynamic TLS altogether, forcing all
TLS into the Static TLS block until it fills up, and failing for good if
it does. But then, you don't need TLS Descriptors at all, just go with
Initial Exec. It helps if init can set the Static TLS block size from
an environment variable or somesuch.
But your statement appears to be conflating two separate issues, namely
the allocation of a TLS Descriptor during lazy TLS resolution, and the
allocation of per-thread dynamic TLS blocks upon first access.
The former is just as easy and harmless to disable as lazy function
relocations. The latter is not exclusive to TLSDesc: __tls_get_addr has
historically used malloc to grow the DTV and to allocate dynamic TLS
blocks, and if overriders to malloc end up using/clobbering unexpected
registers, even if just because of lazy PLT resolution for calls in its
implementation, things might go wrong. Sure enough, __tls_get_addr
doesn't use a specialized ABI, so this is usually not an issue.
> That's actually not a bad idea -- it drops the compare/branch from the
> dynamic tlsdesc code path, and likewise in __tls_get_addr, making both
> forms of dynamic TLS (possibly considerably) faster.
But then you have to add some form of synchronization so that other
threads can actually mess with your DTV without conflicts, from
releasing dlclose()d dynamic blocks to growing the DTV and releasing the
old DTV while its owner thread is using it.
I wonder if it would make sense to introduce an overridable
call-clobbered-regs-preserving wrapper function, that lazy PLT resolvers
and Dynamic TLSDesc calls would call, and that could be easily extended
to preserve extended register files without having to modify the library
proper. LD_PRELOAD could bring it in, and it could even use ifunc
relocations, to be able to cover all available registers on arches with
multiple register file extensions.
--
Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain Engineer Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe