[musl] Draft riscv64 TLSDESC implementation

[musl] Draft riscv64 TLSDESC implementation

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

The psABI work is not finalized, but based on the current status of
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
the attached is a valid (but untested) implementation of TLSDESC for
riscv64. Actually activating it requires also adding the relocation
type macro to riscv64/reloc.h.

If any rv folks could look it over and make sure I haven't made any
stupid asm errors or missed any obvious optimizations, that would help
to quickly get this merged when the psABI is finalized.

Rich

[-- Attachment #2: tlsdesc.s --]
[-- Type: text/plain, Size: 590 bytes --]

.text
.global __tlsdesc_static
.hidden __tlsdesc_static
.type __tlsdesc_static,%function
__tlsdesc_static:
	ld a0,8(a0)
	jr t0

.global __tlsdesc_dynamic
.hidden __tlsdesc_dynamic
.type __tlsdesc_dynamic,%function
__tlsdesc_dynamic:
	add sp,sp,-8
	sd t1,(sp)
	sd t2,8(sp)

	ld t2,-8(tp) # t2=dtv

	ld a0,8(a0)  # a0=&{modidx,off}
	ld t1,8(a0)  # t1=off
	ld a0,(a0)   # a0=modidx
	sll a0,a0,3  # a0=8*modidx

	add a0,a0,t2 # a0=dtv+8*modidx
	ld a0,(a0)   # a0=dtv[modidx]
	add a0,a0,t1 # a0=dtv[modidx]+off
	sub a0,a0,tp # a0=dtv[modidx]+off-tp

	ld t1,(sp)
	ld t2,8(sp)
	add sp,sp,8
	jr t0

Re: [musl] Draft riscv64 TLSDESC implementation

[Rich Felker]

On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> The psABI work is not finalized, but based on the current status of
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> the attached is a valid (but untested) implementation of TLSDESC for
> riscv64. Actually activating it requires also adding the relocation
> type macro to riscv64/reloc.h.
> 
> If any rv folks could look it over and make sure I haven't made any
> stupid asm errors or missed any obvious optimizations, that would help
> to quickly get this merged when the psABI is finalized.
> 
> Rich

> .text
> .global __tlsdesc_static
> .hidden __tlsdesc_static
> .type __tlsdesc_static,%function
> __tlsdesc_static:
> 	ld a0,8(a0)
> 	jr t0
> 
> .global __tlsdesc_dynamic
> .hidden __tlsdesc_dynamic
> .type __tlsdesc_dynamic,%function
> __tlsdesc_dynamic:
> 	add sp,sp,-8
> 	sd t1,(sp)
> 	sd t2,8(sp)
> 
> 	ld t2,-8(tp) # t2=dtv
> 
> 	ld a0,8(a0)  # a0=&{modidx,off}
> 	ld t1,8(a0)  # t1=off
> 	ld a0,(a0)   # a0=modidx
> 	sll a0,a0,3  # a0=8*modidx
> 
> 	add a0,a0,t2 # a0=dtv+8*modidx
> 	ld a0,(a0)   # a0=dtv[modidx]
> 	add a0,a0,t1 # a0=dtv[modidx]+off
> 	sub a0,a0,tp # a0=dtv[modidx]+off-tp
> 
> 	ld t1,(sp)
> 	ld t2,8(sp)
> 	add sp,sp,8
> 	jr t0

Any feedback on this? Offhand, it looks like adjusting sp by 8 is
wrong and that should be 16. Anything else? Does anyone have recent
enough tooling to test this?

Re: [musl] Draft riscv64 TLSDESC implementation

[Fangrui Song]

On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> > The psABI work is not finalized, but based on the current status of
> > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> > the attached is a valid (but untested) implementation of TLSDESC for
> > riscv64. Actually activating it requires also adding the relocation
> > type macro to riscv64/reloc.h.
> >
> > If any rv folks could look it over and make sure I haven't made any
> > stupid asm errors or missed any obvious optimizations, that would help
> > to quickly get this merged when the psABI is finalized.
> >
> > Rich
>
> > .text
> > .global __tlsdesc_static
> > .hidden __tlsdesc_static
> > .type __tlsdesc_static,%function
> > __tlsdesc_static:
> >       ld a0,8(a0)
> >       jr t0
> >
> > .global __tlsdesc_dynamic
> > .hidden __tlsdesc_dynamic
> > .type __tlsdesc_dynamic,%function
> > __tlsdesc_dynamic:
> >       add sp,sp,-8
> >       sd t1,(sp)
> >       sd t2,8(sp)
> >
> >       ld t2,-8(tp) # t2=dtv
> >
> >       ld a0,8(a0)  # a0=&{modidx,off}
> >       ld t1,8(a0)  # t1=off
> >       ld a0,(a0)   # a0=modidx
> >       sll a0,a0,3  # a0=8*modidx
> >
> >       add a0,a0,t2 # a0=dtv+8*modidx
> >       ld a0,(a0)   # a0=dtv[modidx]
> >       add a0,a0,t1 # a0=dtv[modidx]+off
> >       sub a0,a0,tp # a0=dtv[modidx]+off-tp
> >
> >       ld t1,(sp)
> >       ld t2,8(sp)
> >       add sp,sp,8
> >       jr t0
>
> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> wrong and that should be 16. Anything else? Does anyone have recent
> enough tooling to test this?

Tatsuyuki, do you have links to the latest version of
gcc/binutils/glibc patches?
Downloading patches from these mailing lists is probably a large
hurdle for many users, so having the relevant repositories online may
help.

mold has implemented RISC-V TLSDESC.

On the LLVM side, I have reviewed
https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
to land, before I can check the lld status.

Re: [musl] Draft riscv64 TLSDESC implementation

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> > > The psABI work is not finalized, but based on the current status of
> > > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> > > the attached is a valid (but untested) implementation of TLSDESC for
> > > riscv64. Actually activating it requires also adding the relocation
> > > type macro to riscv64/reloc.h.
> > >
> > > If any rv folks could look it over and make sure I haven't made any
> > > stupid asm errors or missed any obvious optimizations, that would help
> > > to quickly get this merged when the psABI is finalized.
> > >
> > > Rich
> >
> > > .text
> > > .global __tlsdesc_static
> > > .hidden __tlsdesc_static
> > > .type __tlsdesc_static,%function
> > > __tlsdesc_static:
> > >       ld a0,8(a0)
> > >       jr t0
> > >
> > > .global __tlsdesc_dynamic
> > > .hidden __tlsdesc_dynamic
> > > .type __tlsdesc_dynamic,%function
> > > __tlsdesc_dynamic:
> > >       add sp,sp,-8
> > >       sd t1,(sp)
> > >       sd t2,8(sp)
> > >
> > >       ld t2,-8(tp) # t2=dtv
> > >
> > >       ld a0,8(a0)  # a0=&{modidx,off}
> > >       ld t1,8(a0)  # t1=off
> > >       ld a0,(a0)   # a0=modidx
> > >       sll a0,a0,3  # a0=8*modidx
> > >
> > >       add a0,a0,t2 # a0=dtv+8*modidx
> > >       ld a0,(a0)   # a0=dtv[modidx]
> > >       add a0,a0,t1 # a0=dtv[modidx]+off
> > >       sub a0,a0,tp # a0=dtv[modidx]+off-tp
> > >
> > >       ld t1,(sp)
> > >       ld t2,8(sp)
> > >       add sp,sp,8
> > >       jr t0
> >
> > Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> > wrong and that should be 16. Anything else? Does anyone have recent
> > enough tooling to test this?
> 
> Tatsuyuki, do you have links to the latest version of
> gcc/binutils/glibc patches?
> Downloading patches from these mailing lists is probably a large
> hurdle for many users, so having the relevant repositories online may
> help.
> 
> mold has implemented RISC-V TLSDESC.
> 
> On the LLVM side, I have reviewed
> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> to land, before I can check the lld status.

To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
arch/riscv64/reloc.h:

#define REL_TLSDESC R_RISCV_TLSDESC

or whatever the reloc name is (I don't think it's in elf.h yet so you
probably need to either add it there too or just hard-code the number
for testing).

Updated version with the sp bugfix attached.

Rich

[-- Attachment #2: tlsdesc.s --]
[-- Type: text/plain, Size: 592 bytes --]

.text
.global __tlsdesc_static
.hidden __tlsdesc_static
.type __tlsdesc_static,%function
__tlsdesc_static:
	ld a0,8(a0)
	jr t0

.global __tlsdesc_dynamic
.hidden __tlsdesc_dynamic
.type __tlsdesc_dynamic,%function
__tlsdesc_dynamic:
	add sp,sp,-16
	sd t1,(sp)
	sd t2,8(sp)

	ld t2,-8(tp) # t2=dtv

	ld a0,8(a0)  # a0=&{modidx,off}
	ld t1,8(a0)  # t1=off
	ld a0,(a0)   # a0=modidx
	sll a0,a0,3  # a0=8*modidx

	add a0,a0,t2 # a0=dtv+8*modidx
	ld a0,(a0)   # a0=dtv[modidx]
	add a0,a0,t1 # a0=dtv[modidx]+off
	sub a0,a0,tp # a0=dtv[modidx]+off-tp

	ld t1,(sp)
	ld t2,8(sp)
	add sp,sp,16
	jr t0

Re: [musl] Draft riscv64 TLSDESC implementation

[Tatsuyuki Ishi]

> On Jan 22, 2024, at 9:03, Rich Felker <dalias@libc.org> wrote:
> 
> On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
>> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
>>> 
>>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
>>>> The psABI work is not finalized, but based on the current status of
>>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
>>>> the attached is a valid (but untested) implementation of TLSDESC for
>>>> riscv64. Actually activating it requires also adding the relocation
>>>> type macro to riscv64/reloc.h.
>>>> 
>>>> If any rv folks could look it over and make sure I haven't made any
>>>> stupid asm errors or missed any obvious optimizations, that would help
>>>> to quickly get this merged when the psABI is finalized.
>>>> 
>>>> Rich
>>> 
>>>> .text
>>>> .global __tlsdesc_static
>>>> .hidden __tlsdesc_static
>>>> .type __tlsdesc_static,%function
>>>> __tlsdesc_static:
>>>>      ld a0,8(a0)
>>>>      jr t0
>>>> 
>>>> .global __tlsdesc_dynamic
>>>> .hidden __tlsdesc_dynamic
>>>> .type __tlsdesc_dynamic,%function
>>>> __tlsdesc_dynamic:
>>>>      add sp,sp,-8
>>>>      sd t1,(sp)
>>>>      sd t2,8(sp)
>>>> 
>>>>      ld t2,-8(tp) # t2=dtv
>>>> 
>>>>      ld a0,8(a0)  # a0=&{modidx,off}
>>>>      ld t1,8(a0)  # t1=off
>>>>      ld a0,(a0)   # a0=modidx
>>>>      sll a0,a0,3  # a0=8*modidx
>>>> 
>>>>      add a0,a0,t2 # a0=dtv+8*modidx
>>>>      ld a0,(a0)   # a0=dtv[modidx]
>>>>      add a0,a0,t1 # a0=dtv[modidx]+off
>>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
>>>> 
>>>>      ld t1,(sp)
>>>>      ld t2,8(sp)
>>>>      add sp,sp,8
>>>>      jr t0
>>> 
>>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
>>> wrong and that should be 16. Anything else? Does anyone have recent
>>> enough tooling to test this?
>> 
>> Tatsuyuki, do you have links to the latest version of
>> gcc/binutils/glibc patches?
>> Downloading patches from these mailing lists is probably a large
>> hurdle for many users, so having the relevant repositories online may
>> help.
>> 
>> mold has implemented RISC-V TLSDESC.
>> 
>> On the LLVM side, I have reviewed
>> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
>> to land, before I can check the lld status.
> 
> To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
> arch/riscv64/reloc.h:
> 
> #define REL_TLSDESC R_RISCV_TLSDESC
> 
> or whatever the reloc name is (I don't think it's in elf.h yet so you
> probably need to either add it there too or just hard-code the number
> for testing).
> 
> Updated version with the sp bugfix attached.

The assembly looks fine to me. (It’s nice that musl don’t need to bother with save/restore at all since DTVs are initialized eagerly.)
For the patches mentioned in the other thread, most tests were done with glibc’s portable testsuite (tst-elf-*).
If musl has a similar one, you should be able to run it with my GCC / binutils fork (with either --with_tls=desc at configure time or -mtls-dialect=desc at compile time).

Tatsuyuki.

> Rich
> <tlsdesc.s>

Re: [musl] Draft riscv64 TLSDESC implementation

[Fangrui Song]

On Sun, Jan 21, 2024 at 7:41 PM Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
>
> > On Jan 22, 2024, at 9:03, Rich Felker <dalias@libc.org> wrote:
> >
> > On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
> >> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
> >>>
> >>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> >>>> The psABI work is not finalized, but based on the current status of
> >>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> >>>> the attached is a valid (but untested) implementation of TLSDESC for
> >>>> riscv64. Actually activating it requires also adding the relocation
> >>>> type macro to riscv64/reloc.h.
> >>>>
> >>>> If any rv folks could look it over and make sure I haven't made any
> >>>> stupid asm errors or missed any obvious optimizations, that would help
> >>>> to quickly get this merged when the psABI is finalized.
> >>>>
> >>>> Rich
> >>>
> >>>> .text
> >>>> .global __tlsdesc_static
> >>>> .hidden __tlsdesc_static
> >>>> .type __tlsdesc_static,%function
> >>>> __tlsdesc_static:
> >>>>      ld a0,8(a0)
> >>>>      jr t0
> >>>>
> >>>> .global __tlsdesc_dynamic
> >>>> .hidden __tlsdesc_dynamic
> >>>> .type __tlsdesc_dynamic,%function
> >>>> __tlsdesc_dynamic:
> >>>>      add sp,sp,-8
> >>>>      sd t1,(sp)
> >>>>      sd t2,8(sp)
> >>>>
> >>>>      ld t2,-8(tp) # t2=dtv
> >>>>
> >>>>      ld a0,8(a0)  # a0=&{modidx,off}
> >>>>      ld t1,8(a0)  # t1=off
> >>>>      ld a0,(a0)   # a0=modidx
> >>>>      sll a0,a0,3  # a0=8*modidx
> >>>>
> >>>>      add a0,a0,t2 # a0=dtv+8*modidx
> >>>>      ld a0,(a0)   # a0=dtv[modidx]
> >>>>      add a0,a0,t1 # a0=dtv[modidx]+off
> >>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
> >>>>
> >>>>      ld t1,(sp)
> >>>>      ld t2,8(sp)
> >>>>      add sp,sp,8
> >>>>      jr t0
> >>>
> >>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> >>> wrong and that should be 16. Anything else? Does anyone have recent
> >>> enough tooling to test this?
> >>
> >> Tatsuyuki, do you have links to the latest version of
> >> gcc/binutils/glibc patches?
> >> Downloading patches from these mailing lists is probably a large
> >> hurdle for many users, so having the relevant repositories online may
> >> help.
> >>
> >> mold has implemented RISC-V TLSDESC.
> >>
> >> On the LLVM side, I have reviewed
> >> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> >> to land, before I can check the lld status.
> >
> > To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
> > arch/riscv64/reloc.h:
> >
> > #define REL_TLSDESC R_RISCV_TLSDESC
> >
> > or whatever the reloc name is (I don't think it's in elf.h yet so you
> > probably need to either add it there too or just hard-code the number
> > for testing).
> >
> > Updated version with the sp bugfix attached.
>
> The assembly looks fine to me. (It’s nice that musl don’t need to bother with save/restore at all since DTVs are initialized eagerly.)
> For the patches mentioned in the other thread, most tests were done with glibc’s portable testsuite (tst-elf-*).
> If musl has a similar one, you should be able to run it with my GCC / binutils fork (with either --with_tls=desc at configure time or -mtls-dialect=desc at compile time).
>
> Tatsuyuki.
>
> > Rich
> > <tlsdesc.s>
>

I have verified that the patch works using a runtime test under qemu-user.
I use Paul Kirth's pending LLVM codegen/assembly patch and my pending
lld patch:)

https://gist.github.com/MaskRay/7ad19393fdb0834540db6e7b6b02fa56 .
Copied instructions below:

Patch musl
```diff
--- c/arch/riscv64/reloc.h
+++ i/arch/riscv64/reloc.h
@@ -17,6 +17,7 @@
 #define REL_DTPMOD      R_RISCV_TLS_DTPMOD64
 #define REL_DTPOFF      R_RISCV_TLS_DTPREL64
 #define REL_TPOFF       R_RISCV_TLS_TPREL64
+#define REL_TLSDESC     12

 #define CRTJMP(pc,sp) __asm__ __volatile__( \
        "mv sp, %1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
diff --git c/src/ldso/riscv64/tlsdesc.s i/src/ldso/riscv64/tlsdesc.s
new file mode 100644
index 00000000..56d1ce89
--- /dev/null
+++ i/src/ldso/riscv64/tlsdesc.s
@@ -0,0 +1,33 @@
+.text
+.global __tlsdesc_static
+.hidden __tlsdesc_static
+.type __tlsdesc_static,%function
+__tlsdesc_static:
+       ld a0,8(a0)
+       jr t0
+
+.global __tlsdesc_dynamic
+.hidden __tlsdesc_dynamic
+.type __tlsdesc_dynamic,%function
+__tlsdesc_dynamic:
+       add sp,sp,-16
+       sd t1,(sp)
+       sd t2,8(sp)
+
+       ld t2,-8(tp) # t2=dtv
+
+       ld a0,8(a0)  # a0=&{modidx,off}
+       ld t1,8(a0)  # t1=off
+       ld a0,(a0)   # a0=modidx
+       sll a0,a0,3  # a0=8*modidx
+
+       add a0,a0,t2 # a0=dtv+8*modidx
+       ld a0,(a0)   # a0=dtv[modidx]
+       add a0,a0,t1 # a0=dtv[modidx]+off
+       sub a0,a0,tp # a0=dtv[modidx]+off-tp
+
+       ld t1,(sp)
+       ld t2,8(sp)
+       add sp,sp,16
+       jr t0
+
```

```sh
(mkdir -p out/rv64 && cd out/rv64 && ../../configure
--target=riscv64-linux-gnu && make -j 50)
```

Adjust `~/musl/out/rv64/lib/musl-gcc.specs` and update
`~/musl/out/rv64/obj/musl-gcc`
```sh
cat > ~/musl/out/rv64/obj/musl-gcc <<eof
#!/bin/sh
exec "${REALGCC:-riscv64-linux-gnu-gcc}" "$@" -specs
~/musl/out/rv64/lib/musl-gcc.specs
eof
```

Use the test at the end of
https://maskray.me/blog/2021-02-14-all-about-thread-local-storage
```sh
cat > ./a.c <<eof
#include <assert.h>
int foo();
int bar();
int main() {
  assert(foo() == 2);
  assert(foo() == 4);
  assert(bar() == 2);
  assert(bar() == 4);
}
eof

cat > ./b.c <<eof
#include <stdio.h>
__thread int tls0;
extern __thread int tls1;
int foo() { return ++tls0 + ++tls1; }
static __thread int tls2, tls3;
int bar() { return ++tls2 + ++tls3; }
eof

echo '__thread int tls1;' > ./c.c

sed 's/        /\t/' > ./Makefile <<'eof'
.MAKE.MODE = meta curDirOk=true

CC := ~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld
LDFLAGS := -Wl,-rpath=.

all: a0 a1 a2

run: all
        ./a0 && ./a1 && ./a2

b.o: bb.s
        /tmp/Rel/bin/clang --target=riscv64-linux -c bb.s -o $@
c.so: c.o; ${LINK.c} -shared $> -o $@
bc.so: b.o c.o; ${LINK.c} -shared $> -o $@
b.so: b.o c.so; ${LINK.c} -shared $> -o $@

a0: a.o b.o c.o; ${LINK.c} $> -o $@
a1: a.o b.so; ${LINK.c} $> -o $@
a2: a.o bc.so; ${LINK.c} $> -o $@
eof
```


Compile b.c to bb.s. Replace general dynamic code sequences (e.g.
`la.tls.gd a0,tls0; call __tls_get_addr@plt`) with TLSDESC, e.g.
```
.Ltlsdesc_hi0:
  auipc a0, %tlsdesc_hi(tls0)
  ld  a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0)
  addi  a0, a0, %tlsdesc_add_lo(.Ltlsdesc_hi0)
  jalr  t0, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0)
  add   a0, a0, tp
```

Apply LLVM CodeGen/assembly and lld patch
(https://github.com/llvm/llvm-project/pull/79099) to llvm-project.
Build clang and lld.
Create an alias `bin/ld.lld` to be used with `-Bbin -fuse-ld=lld`.

`bmake run` => succeeded!

% bmake run
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g  -c a.c
/tmp/Rel/bin/clang --target=riscv64-linux -c bb.s -o b.o
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g  -c c.c
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. a.o b.o c.o -o a0
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. -shared c.o -o c.so
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. -shared b.o c.so -o b.so
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. a.o b.so -o a1
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. -shared b.o c.o -o bc.so
~/musl/out/rv64/obj/musl-gcc -O1 -g -fpic -Bbin -fuse-ld=lld -g
-Wl,-rpath=. a.o bc.so -o a2
./a0 && ./a1 && ./a2

Re: [musl] Draft riscv64 TLSDESC implementation

[Rich Felker]

On Tue, Jan 23, 2024 at 12:52:01AM -0800, Fangrui Song wrote:
> On Sun, Jan 21, 2024 at 7:41 PM Tatsuyuki Ishi <ishitatsuyuki@gmail..com> wrote:
> >
> > > On Jan 22, 2024, at 9:03, Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
> > >> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
> > >>>
> > >>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> > >>>> The psABI work is not finalized, but based on the current status of
> > >>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> > >>>> the attached is a valid (but untested) implementation of TLSDESC for
> > >>>> riscv64. Actually activating it requires also adding the relocation
> > >>>> type macro to riscv64/reloc.h.
> > >>>>
> > >>>> If any rv folks could look it over and make sure I haven't made any
> > >>>> stupid asm errors or missed any obvious optimizations, that would help
> > >>>> to quickly get this merged when the psABI is finalized.
> > >>>>
> > >>>> Rich
> > >>>
> > >>>> .text
> > >>>> .global __tlsdesc_static
> > >>>> .hidden __tlsdesc_static
> > >>>> .type __tlsdesc_static,%function
> > >>>> __tlsdesc_static:
> > >>>>      ld a0,8(a0)
> > >>>>      jr t0
> > >>>>
> > >>>> .global __tlsdesc_dynamic
> > >>>> .hidden __tlsdesc_dynamic
> > >>>> .type __tlsdesc_dynamic,%function
> > >>>> __tlsdesc_dynamic:
> > >>>>      add sp,sp,-8
> > >>>>      sd t1,(sp)
> > >>>>      sd t2,8(sp)
> > >>>>
> > >>>>      ld t2,-8(tp) # t2=dtv
> > >>>>
> > >>>>      ld a0,8(a0)  # a0=&{modidx,off}
> > >>>>      ld t1,8(a0)  # t1=off
> > >>>>      ld a0,(a0)   # a0=modidx
> > >>>>      sll a0,a0,3  # a0=8*modidx
> > >>>>
> > >>>>      add a0,a0,t2 # a0=dtv+8*modidx
> > >>>>      ld a0,(a0)   # a0=dtv[modidx]
> > >>>>      add a0,a0,t1 # a0=dtv[modidx]+off
> > >>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
> > >>>>
> > >>>>      ld t1,(sp)
> > >>>>      ld t2,8(sp)
> > >>>>      add sp,sp,8
> > >>>>      jr t0
> > >>>
> > >>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> > >>> wrong and that should be 16. Anything else? Does anyone have recent
> > >>> enough tooling to test this?
> > >>
> > >> Tatsuyuki, do you have links to the latest version of
> > >> gcc/binutils/glibc patches?
> > >> Downloading patches from these mailing lists is probably a large
> > >> hurdle for many users, so having the relevant repositories online may
> > >> help.
> > >>
> > >> mold has implemented RISC-V TLSDESC.
> > >>
> > >> On the LLVM side, I have reviewed
> > >> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> > >> to land, before I can check the lld status.
> > >
> > > To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
> > > arch/riscv64/reloc.h:
> > >
> > > #define REL_TLSDESC R_RISCV_TLSDESC
> > >
> > > or whatever the reloc name is (I don't think it's in elf.h yet so you
> > > probably need to either add it there too or just hard-code the number
> > > for testing).
> > >
> > > Updated version with the sp bugfix attached.
> >
> > The assembly looks fine to me. (It’s nice that musl don’t need to bother with save/restore at all since DTVs are initialized eagerly..)
> > For the patches mentioned in the other thread, most tests were done with glibc’s portable testsuite (tst-elf-*).
> > If musl has a similar one, you should be able to run it with my GCC / binutils fork (with either --with_tls=desc at configure time or -mtls-dialect=desc at compile time).
> >
> > Tatsuyuki.
> >
> > > Rich
> > > <tlsdesc.s>
> >
> 
> I have verified that the patch works using a runtime test under qemu-user.
> I use Paul Kirth's pending LLVM codegen/assembly patch and my pending
> lld patch:)

Thanks for running tests!

> Compile b.c to bb.s. Replace general dynamic code sequences (e.g.
> `la.tls.gd a0,tls0; call __tls_get_addr@plt`) with TLSDESC, e.g.
> ```
> ..Ltlsdesc_hi0:
>   auipc a0, %tlsdesc_hi(tls0)
>   ld  a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0)
>   addi  a0, a0, %tlsdesc_add_lo(.Ltlsdesc_hi0)
>   jalr  t0, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0)
>   add   a0, a0, tp
> ```

Is this due to compiler not supporting generation of TLSDESC sequence
yet? If so, unlike a full test with compiler support, it does not test
for the TLSDESC machinery honoring all the non-clobbering requirements
of the ABI. But I think we can check by hand that that part of the ABI
is honored.

Rich

Re: [musl] Draft riscv64 TLSDESC implementation

[Fangrui Song]

On Tue, Jan 23, 2024 at 5:26 AM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Jan 23, 2024 at 12:52:01AM -0800, Fangrui Song wrote:
> > On Sun, Jan 21, 2024 at 7:41 PM Tatsuyuki Ishi <ishitatsuyuki@gmail..com> wrote:
> > >
> > > > On Jan 22, 2024, at 9:03, Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
> > > >> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
> > > >>>
> > > >>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> > > >>>> The psABI work is not finalized, but based on the current status of
> > > >>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> > > >>>> the attached is a valid (but untested) implementation of TLSDESC for
> > > >>>> riscv64. Actually activating it requires also adding the relocation
> > > >>>> type macro to riscv64/reloc.h.
> > > >>>>
> > > >>>> If any rv folks could look it over and make sure I haven't made any
> > > >>>> stupid asm errors or missed any obvious optimizations, that would help
> > > >>>> to quickly get this merged when the psABI is finalized.
> > > >>>>
> > > >>>> Rich
> > > >>>
> > > >>>> .text
> > > >>>> .global __tlsdesc_static
> > > >>>> .hidden __tlsdesc_static
> > > >>>> .type __tlsdesc_static,%function
> > > >>>> __tlsdesc_static:
> > > >>>>      ld a0,8(a0)
> > > >>>>      jr t0
> > > >>>>
> > > >>>> .global __tlsdesc_dynamic
> > > >>>> .hidden __tlsdesc_dynamic
> > > >>>> .type __tlsdesc_dynamic,%function
> > > >>>> __tlsdesc_dynamic:
> > > >>>>      add sp,sp,-8
> > > >>>>      sd t1,(sp)
> > > >>>>      sd t2,8(sp)
> > > >>>>
> > > >>>>      ld t2,-8(tp) # t2=dtv
> > > >>>>
> > > >>>>      ld a0,8(a0)  # a0=&{modidx,off}
> > > >>>>      ld t1,8(a0)  # t1=off
> > > >>>>      ld a0,(a0)   # a0=modidx
> > > >>>>      sll a0,a0,3  # a0=8*modidx
> > > >>>>
> > > >>>>      add a0,a0,t2 # a0=dtv+8*modidx
> > > >>>>      ld a0,(a0)   # a0=dtv[modidx]
> > > >>>>      add a0,a0,t1 # a0=dtv[modidx]+off
> > > >>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
> > > >>>>
> > > >>>>      ld t1,(sp)
> > > >>>>      ld t2,8(sp)
> > > >>>>      add sp,sp,8
> > > >>>>      jr t0
> > > >>>
> > > >>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> > > >>> wrong and that should be 16. Anything else? Does anyone have recent
> > > >>> enough tooling to test this?
> > > >>
> > > >> Tatsuyuki, do you have links to the latest version of
> > > >> gcc/binutils/glibc patches?
> > > >> Downloading patches from these mailing lists is probably a large
> > > >> hurdle for many users, so having the relevant repositories online may
> > > >> help.
> > > >>
> > > >> mold has implemented RISC-V TLSDESC.
> > > >>
> > > >> On the LLVM side, I have reviewed
> > > >> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> > > >> to land, before I can check the lld status.
> > > >
> > > > To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
> > > > arch/riscv64/reloc.h:
> > > >
> > > > #define REL_TLSDESC R_RISCV_TLSDESC
> > > >
> > > > or whatever the reloc name is (I don't think it's in elf.h yet so you
> > > > probably need to either add it there too or just hard-code the number
> > > > for testing).
> > > >
> > > > Updated version with the sp bugfix attached.
> > >
> > > The assembly looks fine to me. (It’s nice that musl don’t need to bother with save/restore at all since DTVs are initialized eagerly..)
> > > For the patches mentioned in the other thread, most tests were done with glibc’s portable testsuite (tst-elf-*).
> > > If musl has a similar one, you should be able to run it with my GCC / binutils fork (with either --with_tls=desc at configure time or -mtls-dialect=desc at compile time).
> > >
> > > Tatsuyuki.
> > >
> > > > Rich
> > > > <tlsdesc.s>
> > >
> >
> > I have verified that the patch works using a runtime test under qemu-user.
> > I use Paul Kirth's pending LLVM codegen/assembly patch and my pending
> > lld patch:)
>
> Thanks for running tests!
>
> > Compile b.c to bb.s. Replace general dynamic code sequences (e.g.
> > `la.tls.gd a0,tls0; call __tls_get_addr@plt`) with TLSDESC, e.g.
> > ```
> > ..Ltlsdesc_hi0:
> >   auipc a0, %tlsdesc_hi(tls0)
> >   ld  a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0)
> >   addi  a0, a0, %tlsdesc_add_lo(.Ltlsdesc_hi0)
> >   jalr  t0, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0)
> >   add   a0, a0, tp
> > ```
>
> Is this due to compiler not supporting generation of TLSDESC sequence
> yet?

LLVM assembler and code gen support has been added
(https://github.com/llvm/llvm-project/pull/66915/files),
but the clang -mtls-dialect=desc part has not landed yet
(https://github.com/llvm/llvm-project/pull/79256).

> If so, unlike a full test with compiler support, it does not test
> for the TLSDESC machinery honoring all the non-clobbering requirements
> of the ABI. But I think we can check by hand that that part of the ABI
> is honored.
>
> Rich

Yes.

% cat a.c
__thread int x;
void ext(int a, int b, int c, int d, int e, int f);
int foo(int a, int b, int c, int d, int e, int f) {
  int ret = ++x;
  ext(a, b, c, d, e, f);
  return ret;
}
% clang --target=riscv64 -mtls-dialect=desc -O1 -S a.c -fpic -o desc.s
# patched clang with -mtls-dialect=

We can verify that a0~a5 (the resigers holding arguments) are not spilled :)

BTW, when you add static relocation types to include/elf.h, be sure
that the `_I` suffix is not included
(typos in the spec, which will be fixed by
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/420)

Re: [musl] Draft riscv64 TLSDESC implementation

[Fangrui Song]

On Wed, Jan 24, 2024 at 10:48 PM Fangrui Song <i@maskray.me> wrote:
>
> On Tue, Jan 23, 2024 at 5:26 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Tue, Jan 23, 2024 at 12:52:01AM -0800, Fangrui Song wrote:
> > > On Sun, Jan 21, 2024 at 7:41 PM Tatsuyuki Ishi <ishitatsuyuki@gmail..com> wrote:
> > > >
> > > > > On Jan 22, 2024, at 9:03, Rich Felker <dalias@libc.org> wrote:
> > > > >
> > > > > On Sun, Jan 21, 2024 at 03:48:55PM -0800, Fangrui Song wrote:
> > > > >> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
> > > > >>>
> > > > >>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
> > > > >>>> The psABI work is not finalized, but based on the current status of
> > > > >>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
> > > > >>>> the attached is a valid (but untested) implementation of TLSDESC for
> > > > >>>> riscv64. Actually activating it requires also adding the relocation
> > > > >>>> type macro to riscv64/reloc.h.
> > > > >>>>
> > > > >>>> If any rv folks could look it over and make sure I haven't made any
> > > > >>>> stupid asm errors or missed any obvious optimizations, that would help
> > > > >>>> to quickly get this merged when the psABI is finalized.
> > > > >>>>
> > > > >>>> Rich
> > > > >>>
> > > > >>>> .text
> > > > >>>> .global __tlsdesc_static
> > > > >>>> .hidden __tlsdesc_static
> > > > >>>> .type __tlsdesc_static,%function
> > > > >>>> __tlsdesc_static:
> > > > >>>>      ld a0,8(a0)
> > > > >>>>      jr t0
> > > > >>>>
> > > > >>>> .global __tlsdesc_dynamic
> > > > >>>> .hidden __tlsdesc_dynamic
> > > > >>>> .type __tlsdesc_dynamic,%function
> > > > >>>> __tlsdesc_dynamic:
> > > > >>>>      add sp,sp,-8
> > > > >>>>      sd t1,(sp)
> > > > >>>>      sd t2,8(sp)
> > > > >>>>
> > > > >>>>      ld t2,-8(tp) # t2=dtv
> > > > >>>>
> > > > >>>>      ld a0,8(a0)  # a0=&{modidx,off}
> > > > >>>>      ld t1,8(a0)  # t1=off
> > > > >>>>      ld a0,(a0)   # a0=modidx
> > > > >>>>      sll a0,a0,3  # a0=8*modidx
> > > > >>>>
> > > > >>>>      add a0,a0,t2 # a0=dtv+8*modidx
> > > > >>>>      ld a0,(a0)   # a0=dtv[modidx]
> > > > >>>>      add a0,a0,t1 # a0=dtv[modidx]+off
> > > > >>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
> > > > >>>>
> > > > >>>>      ld t1,(sp)
> > > > >>>>      ld t2,8(sp)
> > > > >>>>      add sp,sp,8
> > > > >>>>      jr t0
> > > > >>>
> > > > >>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
> > > > >>> wrong and that should be 16. Anything else? Does anyone have recent
> > > > >>> enough tooling to test this?
> > > > >>
> > > > >> Tatsuyuki, do you have links to the latest version of
> > > > >> gcc/binutils/glibc patches?
> > > > >> Downloading patches from these mailing lists is probably a large
> > > > >> hurdle for many users, so having the relevant repositories online may
> > > > >> help.
> > > > >>
> > > > >> mold has implemented RISC-V TLSDESC.
> > > > >>
> > > > >> On the LLVM side, I have reviewed
> > > > >> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> > > > >> to land, before I can check the lld status.
> > > > >
> > > > > To test this, drop it in src/ldso/riscv64/tlsdesc.s, and add to
> > > > > arch/riscv64/reloc.h:
> > > > >
> > > > > #define REL_TLSDESC R_RISCV_TLSDESC
> > > > >
> > > > > or whatever the reloc name is (I don't think it's in elf.h yet so you
> > > > > probably need to either add it there too or just hard-code the number
> > > > > for testing).
> > > > >
> > > > > Updated version with the sp bugfix attached.
> > > >
> > > > The assembly looks fine to me. (It’s nice that musl don’t need to bother with save/restore at all since DTVs are initialized eagerly..)
> > > > For the patches mentioned in the other thread, most tests were done with glibc’s portable testsuite (tst-elf-*).
> > > > If musl has a similar one, you should be able to run it with my GCC / binutils fork (with either --with_tls=desc at configure time or -mtls-dialect=desc at compile time).
> > > >
> > > > Tatsuyuki.
> > > >
> > > > > Rich
> > > > > <tlsdesc.s>
> > > >
> > >
> > > I have verified that the patch works using a runtime test under qemu-user.
> > > I use Paul Kirth's pending LLVM codegen/assembly patch and my pending
> > > lld patch:)
> >
> > Thanks for running tests!
> >
> > > Compile b.c to bb.s. Replace general dynamic code sequences (e.g.
> > > `la.tls.gd a0,tls0; call __tls_get_addr@plt`) with TLSDESC, e.g.
> > > ```
> > > ..Ltlsdesc_hi0:
> > >   auipc a0, %tlsdesc_hi(tls0)
> > >   ld  a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0)
> > >   addi  a0, a0, %tlsdesc_add_lo(.Ltlsdesc_hi0)
> > >   jalr  t0, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0)
> > >   add   a0, a0, tp
> > > ```
> >
> > Is this due to compiler not supporting generation of TLSDESC sequence
> > yet?
>
> LLVM assembler and code gen support has been added
> (https://github.com/llvm/llvm-project/pull/66915/files),
> but the clang -mtls-dialect=desc part has not landed yet
> (https://github.com/llvm/llvm-project/pull/79256).
>
> > If so, unlike a full test with compiler support, it does not test
> > for the TLSDESC machinery honoring all the non-clobbering requirements
> > of the ABI. But I think we can check by hand that that part of the ABI
> > is honored.
> >
> > Rich
>
> Yes.
>
> % cat a.c
> __thread int x;
> void ext(int a, int b, int c, int d, int e, int f);
> int foo(int a, int b, int c, int d, int e, int f) {
>   int ret = ++x;
>   ext(a, b, c, d, e, f);
>   return ret;
> }
> % clang --target=riscv64 -mtls-dialect=desc -O1 -S a.c -fpic -o desc.s
> # patched clang with -mtls-dialect=
>
> We can verify that a0~a5 (the resigers holding arguments) are not spilled :)
>
> BTW, when you add static relocation types to include/elf.h, be sure
> that the `_I` suffix is not included
> (typos in the spec, which will be fixed by
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/420)

The aforementioned patches (LLVM, Clang, lld) have all landed in the
main branch of llvm-project.
I have filed cherry-pick requests for them to the upcoming 18.1
release (https://github.com/llvm/llvm-project/commits/release/18.x/)

Rich, you may consider merging
https://www.openwall.com/lists/musl/2024/01/26/9 ("elf.h: update
RISC-V relocation types") first,
so that your RISC-V TLSDESC patch does not need to touch include/elf.h

Cheers

Re: [musl] Draft riscv64 TLSDESC implementation

[Tatsuyuki Ishi]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

> On Jan 22, 2024, at 8:48, Fangrui Song <i@maskray.me> wrote:
> 
> On Sun, Jan 21, 2024 at 2:28 PM Rich Felker <dalias@libc.org> wrote:
>> 
>> On Tue, Aug 22, 2023 at 01:38:21PM -0400, Rich Felker wrote:
>>> The psABI work is not finalized, but based on the current status of
>>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, I think
>>> the attached is a valid (but untested) implementation of TLSDESC for
>>> riscv64. Actually activating it requires also adding the relocation
>>> type macro to riscv64/reloc.h.
>>> 
>>> If any rv folks could look it over and make sure I haven't made any
>>> stupid asm errors or missed any obvious optimizations, that would help
>>> to quickly get this merged when the psABI is finalized.
>>> 
>>> Rich
>> 
>>> .text
>>> .global __tlsdesc_static
>>> .hidden __tlsdesc_static
>>> .type __tlsdesc_static,%function
>>> __tlsdesc_static:
>>>      ld a0,8(a0)
>>>      jr t0
>>> 
>>> .global __tlsdesc_dynamic
>>> .hidden __tlsdesc_dynamic
>>> .type __tlsdesc_dynamic,%function
>>> __tlsdesc_dynamic:
>>>      add sp,sp,-8
>>>      sd t1,(sp)
>>>      sd t2,8(sp)
>>> 
>>>      ld t2,-8(tp) # t2=dtv
>>> 
>>>      ld a0,8(a0)  # a0=&{modidx,off}
>>>      ld t1,8(a0)  # t1=off
>>>      ld a0,(a0)   # a0=modidx
>>>      sll a0,a0,3  # a0=8*modidx
>>> 
>>>      add a0,a0,t2 # a0=dtv+8*modidx
>>>      ld a0,(a0)   # a0=dtv[modidx]
>>>      add a0,a0,t1 # a0=dtv[modidx]+off
>>>      sub a0,a0,tp # a0=dtv[modidx]+off-tp
>>> 
>>>      ld t1,(sp)
>>>      ld t2,8(sp)
>>>      add sp,sp,8
>>>      jr t0
>> 
>> Any feedback on this? Offhand, it looks like adjusting sp by 8 is
>> wrong and that should be 16. Anything else? Does anyone have recent
>> enough tooling to test this?
> 
> Tatsuyuki, do you have links to the latest version of
> gcc/binutils/glibc patches?

The latest revisions are at [1,2,3]. I have plans to do a revision on binutils for more tests, and glibc for supporting saving vector registers, but I’m occupied with other priorities until the end of January.

> Downloading patches from these mailing lists is probably a large
> hurdle for many users, so having the relevant repositories online may
> help.

I’ll also link my GitHub repositories containing the same code at [4,5,6]. Right now they have some WIP commits (planned for sending in newer revisions) added on top, but they should still work fine.

[1]: https://inbox.sourceware.org/binutils/20231128085109.28422-1-ishitatsuyuki@gmail.com/
[2]: https://inbox.sourceware.org/libc-alpha/20230914084033.222120-1-ishitatsuyuki@gmail.com/
[3]: https://inbox.sourceware.org/gcc-patches/20231205070152.38360-1-ishitatsuyuki@gmail.com/
[4]: https://github.com/ishitatsuyuki/binutils/tree/rv-tlsdesc
[5]: https://github.com/ishitatsuyuki/glibc/tree/rv-tlsdesc/
[6]: https://github.com/ishitatsuyuki/gcc/tree/rv-tlsdesc/

Tatsuyuki.

> mold has implemented RISC-V TLSDESC.
> 
> On the LLVM side, I have reviewed
> https://github.com/llvm/llvm-project/pull/66915 and am waiting for it
> to land, before I can check the lld status.


[-- Attachment #2: Type: text/html, Size: 4796 bytes --]