Support Thread-Local Storage Descriptors (TLSDESC)

[MaskRay]

TLSDESC (-mtls-dialect=gnu2) improves traditional General Dynamic and Local Dynamic TLS models (-mtls-dialect=gnu). In the most common case that TLS variables are defined in initially-loaded modules, it simplifies the work in __tls_get_addr and (probably more importantly) switches to a custom calling convention that doesn't clobber any register ("preserve any registers they modify"). This speedup is significant.

The linker may relax TLSDESC code sequence to Initial Exec (targeting an executable, the symbol is preemptable) or Local Exec (target an executable, the symbol is non-preemptable) if applicable.

The initial (static) and outstanding (dynamic) relocation types for TLSDESC have to be defined, as well as how static relocation types are relaxed to Initial Exec and Local Exec models.

TLSDESC is currently available on x86, x86-64, arm and aarch64.

x86: https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
ARM: https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-ARM.txt (the published paper was referenced by ELF for the Arm 64-bit Architecture (AArch64) and ARM 32-bit)

As I understand it, TLSDESC is a strict improvement, so it might be worth defaulting to TLSDESC and probably deprecating relocation types for General Dynamic/Local Dynamic.

[aswaterman]

Seems like a good idea, though a big chunk of work to specify and implement. Any chance you're volunteering? :)

[MaskRay]

I'm still getting my feet wet with riscv toolchain (tracking the progress of musl-riscv, reading llvm/lib/Target/RISCV binutils-gdb/bfd/elf*-riscv.c, etc)... but I would be happy if I can help. I have some contribution to lld so I may help on the lld (llvm linker) side.

[richfelker]

One note based on comments from sorear on #musl where this was discussed earlier: since TLSDESC calls have a custom calling convention (usually with few or no clobbers) anyway, it would probably make sense to use a non-default link register for the call. This would avoid the need for the caller to save and restore it.

[aswaterman]

Indeed, t0 is intended for this purpose.

[rui314]

It looks like no progress has been made since this was filed, but I'd like to see this to happen. Compared to the current TLS model, TLSDESC is strictly better; it's more generic, more efficient and simpler.

[aswaterman]

I don’t think there’s any disagreement on the technical merits. Someone needs to volunteer to do the work.

Many of the folks who work on the toolchain are doing the things their employers think are the most pressing, and this one doesn’t seem to be reaching the top of anyone’s list. So, unless someone volunteers to do it out of the goodness of their hearts, it’ll probably be a few more years.

[rui314]

I understand that. I'm currently busy working on my mold linker (which by the way supports RISC-V), so I don't have a bandwidth to take this one, but if someone wants to take this, I'm happy to support.

[aswaterman]

@rui314 mold looks like a great project!

[ishitatsuyuki]

I'm planning to prototype on an implementation (with draft spec) in the following weeks. I'll keep you updated when I make progress.

[aswaterman]

Cool!

[rui314]

I'm proud to say that this effort is sponsored by the mold project. We are interested in not only implementing but also improving the RISC-V psABI.