[PATCH v3 0/9] RISC-V: Implement TLS Descriptors.

[Fangrui Song]

On Tue, Dec 12, 2023 at 5:53 PM Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
>
> On Dec 13, 2023, at 9:27, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 06 Dec 2023 19:35:00 PST (-0800), i@maskray.me wrote:
>
> On Tue, Dec 5, 2023 at 4:33 PM Nelson Chu <nelson@rivosinc.com> wrote:
>
>
> Sorry that I don't familiar with the TLS stuff and TLS descriptor, so I will need more time to figure these out if other maintainers are all busy.  Since there are other patches which are also being reviewed, if someone thinks this is an urgent matter, please feel free to let us know, so we can switch to see these first.
>
>
> I know that Android wants TLSDESC and having TLSDESC in gcc/binutils
> helps check LLVM feature parity...
> If we have TLSDESC earlier, an OS with a new RISC-V port can make
> TLSDESC part of the baseline ABI...
>
> On Wed, Dec 6, 2023 at 12:44 AM Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
>
>
> > On Nov 28, 2023, at 17:51, Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
> >
> > This patchset implements TLS Descriptors (TLSDESC) for RISC-V targets, per
> > the specification (merged) at [1].
> >
> > Tested on rv64gc for:
> > - No regression (& passing new tests) in binutils
> > - No regression in gcc
> > - No regression in glibc for subdirs=elf
> > With both -mtls-dialect=desc and trad.
> >
> > This contribution is made on behalf of Blue Whale Systems, which has
> > copyright assignment on file with the FSF.
> >
> > [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373
> >
> > v2: Add changelogs and tests. Minor fixes described in patch messages.
> > v3: Add relaxation support. This fixes tst-tls1-static in glibc.
>
> Would anyone like to review this?  This is a prerequisite for the GCC-side
> implementation to be useful (especially the gas part).
>
>
>
> For these huge features, gcc/binutils/glibc should be reviewed at the same time, since all the stuff should be bound and tested together, so "prerequisite" shouldn't apply here ;)
>
>
> Ya, I agree.  It's super hard to review stuff like this without seeing all the code, doubly so now that the psABI has turned into a wasteland for discussions.
>
>
> Thanks
> Nelson
>
>
> Agreed. I wonder whether Wei can find someone to test
> gcc/binutils/glibc patches... and some packages using TLS (e.g.
> https://codesearch.debian.net/search?q=__thread&literal=1).
>
>
> Do you guys have a pointer to the glibc code?  I can't find it, but I'm happy to poke it (or maybe find someone else who to poke it...).
>
>
> Hi,
> The glibc and gcc patches are available at [1] and [2] respectively.
> For glibc, I still need to implement save/restore stubs for vector ABI, but apart from that it should be functional.
>
> [1]: https://inbox.sourceware.org/libc-alpha/20230914084033.222120-1-ishitatsuyuki@gmail.com/
> [2]: https://inbox.sourceware.org/gcc-patches/20231205070152.38360-1-ishitatsuyuki@gmail.com/
>
> Tatsuyuki.
>
>
>
>
> I can split up the series into bug fix / refactors and actual changes if
> desired.

On the LLVM side, the RISC-V TLSDESC work (LLVM, Clang, lld) has been
completed today.
(I will frequently update
https://maskray.me/blog/2024-01-23-riscv-tlsdesc-works to track the
status.)
I filed cherry-pick requests into the upcoming 18.1 release.

We postponed the LLVM change to add R_RISCV_RELAX when relaxation is
in effect. That one will not go to the 18.x releases for safety.

If the gas patch is to add one R_RISCV_RELAX to each of the 4 instructions.
Perhaps it can be adjusted to add just one per
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/421 ?

I haven't checked, but for the ld patch, you probably want to consider
TLSDESC to LE/IE optimization regardless of R_RISCV_RELAX.
TLSDESC to LE optimization is essential if a libc doesn't implement
R_RISCV_TLSDESC in its resolocation resolver for a statically linkeded
executable.

It seems that musl will merge the RISC-V TLSDESC patch soon
(https://www.openwall.com/lists/musl/2024/01/27/1 , CCed Tatsuyuki
there).
So even if glibc will take some time to be ready, we will still have a
testable libc :)