On Oct 11, 2018, Rich Felker <dal...@libc.org> wrote: > This is indeed the big risk for glibc right now (with lazy, > non-fail-safe allocation of dynamic TLS)
Yeah, dynamic TLS was a can of works in that regard even before lazy TLS relocations. > that it's unlikely for vector-heavy code to be using TLS where the TLS > address load can't be hoisted out of the blocks where the > call-clobbered vector regs are in use. Generally, if such hoisting is > performed, the main/only advantage of avoiding clobbers is for > registers which may contain incoming arguments. I see. Well, the more registers are preserved, the better for the ideal fast path, but even if some are not, you're still better off than explicitly calling tls_get_addr... > unless there is some future-proof approach to > save-all/restore-all that works on all archs with TLSDESC Please don't single-out TLSDESC as if the problem affected it alone. Lazy relocation with traditional PLT entries for functions are also supposed to save and restore all registers, and the same issues arise, except they're a lot more common. The only difference is that failures to preserve registers are less visible, because most of the time you're resolving them to functions that abide by the normal ABI, but once specialized calling conventions kick in, the very same issues arise. TLS descriptors are just one case of such specialized calling conventions. Indeed, one of the reasons that made me decide this arrangement was acceptable was precisely because the problem already existed with preexisting lazy PLT resolution. -- 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
