* [musl] loongarch64 atomics not working? @ 2024-03-12 0:51 Rich Felker 2024-03-12 2:06 ` Hongliang Wang 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2024-03-12 0:51 UTC (permalink / raw) To: musl; +Cc: Hongliang Wang There's been a report of mksh hanging on loongarch64, at least under qemu, apparently hanging in a_cas_p: (gdb) run Starting program: /mksh ^C Program received signal SIGINT, Interrupt. a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, s=0x7fffffffc34c) at ./src/internal/atomic.h:94 warning: 94 ./src/internal/atomic.h: No such file or directory (gdb) bt #0 a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, s=0x7fffffffc34c) at ./src/internal/atomic.h:94 #1 cgt_init (clk=0, ts=0x7ffffffefb60) at src/time/clock_gettime.c:51 #2 0x000000012003ba4c in __clock_gettime (clk=clk@entry=0, ts=ts@entry=0x7ffffffefb60) at src/time/clock_gettime.c:67 #3 0x000000012003830c in gettimeofday (tv=tv@entry=0x7ffffffefba0, tz=tz@entry=0x0) at src/time/gettimeofday.c:9 #4 0x000000012002f098 in change_winsz () at var.c:1718 #5 0x0000000120000348 in main_init (lp=<synthetic pointer>, sp=<synthetic pointer>, argv=0x7ffffffefd18, argc=1) at main.c:369 #6 main (argc=<optimized out>, argv=<optimized out>) at main.c:738 This is very basic usage, just the vdso clock_gettime init code trying to replace a pointer atomically. Is it working on real hardware? I'm trying to figure out if this is a qemu bug, or if the asm or the asm argument constraints are wrong in musl's arch/loongarch64/atomic_arch.h. Rich ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 0:51 [musl] loongarch64 atomics not working? Rich Felker @ 2024-03-12 2:06 ` Hongliang Wang 2024-03-12 8:31 ` lixing 2024-03-12 8:48 ` Jingyun Hua 0 siblings, 2 replies; 14+ messages in thread From: Hongliang Wang @ 2024-03-12 2:06 UTC (permalink / raw) To: musl 在 2024/3/12 上午8:51, Rich Felker 写道: > There's been a report of mksh hanging on loongarch64, at least under > qemu, apparently hanging in a_cas_p: > > (gdb) run > Starting program: /mksh > ^C > Program received signal SIGINT, Interrupt. > a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, s=0x7fffffffc34c) > at ./src/internal/atomic.h:94 > warning: 94 ./src/internal/atomic.h: No such file or directory > (gdb) bt > #0 a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, > s=0x7fffffffc34c) at ./src/internal/atomic.h:94 > #1 cgt_init (clk=0, ts=0x7ffffffefb60) at src/time/clock_gettime.c:51 > #2 0x000000012003ba4c in __clock_gettime (clk=clk@entry=0, > ts=ts@entry=0x7ffffffefb60) at src/time/clock_gettime.c:67 > #3 0x000000012003830c in gettimeofday (tv=tv@entry=0x7ffffffefba0, > tz=tz@entry=0x0) at src/time/gettimeofday.c:9 > #4 0x000000012002f098 in change_winsz () at var.c:1718 > #5 0x0000000120000348 in main_init (lp=<synthetic pointer>, > sp=<synthetic pointer>, argv=0x7ffffffefd18, argc=1) at main.c:369 > #6 main (argc=<optimized out>, argv=<optimized out>) at main.c:738 > > This is very basic usage, just the vdso clock_gettime init code trying > to replace a pointer atomically. Is it working on real hardware? I'm > trying to figure out if this is a qemu bug, or if the asm or the asm > argument constraints are wrong in musl's > arch/loongarch64/atomic_arch.h. > > Rich > We will test it on real hardware to confirm if it can work as soon as possible. Regards, Hongliang Wang ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 2:06 ` Hongliang Wang @ 2024-03-12 8:31 ` lixing 2024-03-12 16:18 ` Waldemar Brodkorb 2024-03-12 8:48 ` Jingyun Hua 1 sibling, 1 reply; 14+ messages in thread From: lixing @ 2024-03-12 8:31 UTC (permalink / raw) To: musl 在 2024/3/12 上午10:06, Hongliang Wang 写道: > > > 在 2024/3/12 上午8:51, Rich Felker 写道: >> There's been a report of mksh hanging on loongarch64, at least under >> qemu, apparently hanging in a_cas_p: >> >> (gdb) run >> Starting program: /mksh >> ^C >> Program received signal SIGINT, Interrupt. >> a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, >> s=0x7fffffffc34c) >> at ./src/internal/atomic.h:94 >> warning: 94 ./src/internal/atomic.h: No such file or directory >> (gdb) bt >> #0 a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, >> s=0x7fffffffc34c) at ./src/internal/atomic.h:94 >> #1 cgt_init (clk=0, ts=0x7ffffffefb60) at src/time/clock_gettime.c:51 >> #2 0x000000012003ba4c in __clock_gettime (clk=clk@entry=0, >> ts=ts@entry=0x7ffffffefb60) at src/time/clock_gettime.c:67 >> #3 0x000000012003830c in gettimeofday (tv=tv@entry=0x7ffffffefba0, >> tz=tz@entry=0x0) at src/time/gettimeofday.c:9 >> #4 0x000000012002f098 in change_winsz () at var.c:1718 >> #5 0x0000000120000348 in main_init (lp=<synthetic pointer>, >> sp=<synthetic pointer>, argv=0x7ffffffefd18, argc=1) at main.c:369 >> #6 main (argc=<optimized out>, argv=<optimized out>) at main.c:738 >> >> This is very basic usage, just the vdso clock_gettime init code trying >> to replace a pointer atomically. Is it working on real hardware? I'm >> trying to figure out if this is a qemu bug, or if the asm or the asm >> argument constraints are wrong in musl's >> arch/loongarch64/atomic_arch.h. >> >> Rich >> > > We will test it on real hardware to confirm if it can work as soon as > possible. > > Regards, > Hongliang Wang Hi, Rich We've tested static and dynamic build mksh with commit id cbb8a0196aab53165a35339fd91ade599d184f both works ok. We compiled qemu 8.2.2 with the following configuration: ./configure --prefix=/usr --target-list=loongarch64-linux-user --disable-werror --static --disable-docs then run with qemu-loongarch64 ./mksh without hang. Thanks, XingLi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 8:31 ` lixing @ 2024-03-12 16:18 ` Waldemar Brodkorb 2024-03-12 16:47 ` Thorsten Glaser 0 siblings, 1 reply; 14+ messages in thread From: Waldemar Brodkorb @ 2024-03-12 16:18 UTC (permalink / raw) To: musl Hi, lixing wrote, > > 在 2024/3/12 上午10:06, Hongliang Wang 写道: > > > > > > 在 2024/3/12 上午8:51, Rich Felker 写道: > > > There's been a report of mksh hanging on loongarch64, at least under > > > qemu, apparently hanging in a_cas_p: > > > > > > (gdb) run > > > Starting program: /mksh > > > ^C > > > Program received signal SIGINT, Interrupt. > > > a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, > > > s=0x7fffffffc34c) > > > at ./src/internal/atomic.h:94 > > > warning: 94 ./src/internal/atomic.h: No such file or directory > > > (gdb) bt > > > #0 a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, > > > s=0x7fffffffc34c) at ./src/internal/atomic.h:94 > > > #1 cgt_init (clk=0, ts=0x7ffffffefb60) at src/time/clock_gettime.c:51 > > > #2 0x000000012003ba4c in __clock_gettime (clk=clk@entry=0, > > > ts=ts@entry=0x7ffffffefb60) at src/time/clock_gettime.c:67 > > > #3 0x000000012003830c in gettimeofday (tv=tv@entry=0x7ffffffefba0, > > > tz=tz@entry=0x0) at src/time/gettimeofday.c:9 > > > #4 0x000000012002f098 in change_winsz () at var.c:1718 > > > #5 0x0000000120000348 in main_init (lp=<synthetic pointer>, > > > sp=<synthetic pointer>, argv=0x7ffffffefd18, argc=1) at main.c:369 > > > #6 main (argc=<optimized out>, argv=<optimized out>) at main.c:738 > > > > > > This is very basic usage, just the vdso clock_gettime init code trying > > > to replace a pointer atomically. Is it working on real hardware? I'm > > > trying to figure out if this is a qemu bug, or if the asm or the asm > > > argument constraints are wrong in musl's > > > arch/loongarch64/atomic_arch.h. > > > > > > Rich > > > > > > > We will test it on real hardware to confirm if it can work as soon as > > possible. > > > > Regards, > > Hongliang Wang > > Hi, Rich > > We've tested static and dynamic build mksh with commit id > cbb8a0196aab53165a35339fd91ade599d184f both works ok. > > We compiled qemu 8.2.2 with the following configuration: > > ./configure --prefix=/usr --target-list=loongarch64-linux-user > --disable-werror --static --disable-docs > > then run with qemu-loongarch64 ./mksh without hang. Can you check with qemu-system-loongarch64? I use gcc 13.2.0, binutils 2.42 and Linux 6.6.18 with the defconfig provided. Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? For me it hangs. best regards Waldemar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 16:18 ` Waldemar Brodkorb @ 2024-03-12 16:47 ` Thorsten Glaser 2024-03-12 17:18 ` Waldemar Brodkorb 0 siblings, 1 reply; 14+ messages in thread From: Thorsten Glaser @ 2024-03-12 16:47 UTC (permalink / raw) To: musl Waldemar Brodkorb dixit: >lixing wrote, >> We've tested static and dynamic build mksh with commit id >> cbb8a0196aab53165a35339fd91ade599d184f both works ok. That’s great to hear! >Can you check with qemu-system-loongarch64? I use gcc 13.2.0, >binutils 2.42 and Linux 6.6.18 with the defconfig provided. >Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? Perhaps to distinguish between emulation/runtime and toolchain faults you could send each other the mksh binaries (if statically linked, otherwise probably them plus musl’s dynamic parts)? gl hf, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 16:47 ` Thorsten Glaser @ 2024-03-12 17:18 ` Waldemar Brodkorb 2024-03-13 1:42 ` lixing 0 siblings, 1 reply; 14+ messages in thread From: Waldemar Brodkorb @ 2024-03-12 17:18 UTC (permalink / raw) To: musl Hi Thorsten, Thorsten Glaser wrote, > Waldemar Brodkorb dixit: > > >lixing wrote, > > >> We've tested static and dynamic build mksh with commit id > >> cbb8a0196aab53165a35339fd91ade599d184f both works ok. > > That’s great to hear! > > >Can you check with qemu-system-loongarch64? I use gcc 13.2.0, > >binutils 2.42 and Linux 6.6.18 with the defconfig provided. > >Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? > > Perhaps to distinguish between emulation/runtime and toolchain > faults you could send each other the mksh binaries (if statically > linked, otherwise probably them plus musl’s dynamic parts)? Statically linked mksh from me is here: https://debug.openadk.org/mksh best regards Waldemar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 17:18 ` Waldemar Brodkorb @ 2024-03-13 1:42 ` lixing 2024-03-13 14:45 ` Waldemar Brodkorb 0 siblings, 1 reply; 14+ messages in thread From: lixing @ 2024-03-13 1:42 UTC (permalink / raw) To: musl 在 2024/3/13 上午1:18, Waldemar Brodkorb 写道: > Hi Thorsten, > Thorsten Glaser wrote, > >> Waldemar Brodkorb dixit: >> >>> lixing wrote, >>>> We've tested static and dynamic build mksh with commit id >>>> cbb8a0196aab53165a35339fd91ade599d184f both works ok. >> That’s great to hear! >> >>> Can you check with qemu-system-loongarch64? I use gcc 13.2.0, >>> binutils 2.42 and Linux 6.6.18 with the defconfig provided. >>> Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? I just only use qemu user mode, but my colleague give me the address for download the EFI as follow https://github.com/lixianglai/LoongarchVirtFirmware. Also, can you post the qemu-system-loongarch64 startup command to me? >> Perhaps to distinguish between emulation/runtime and toolchain >> faults you could send each other the mksh binaries (if statically >> linked, otherwise probably them plus musl’s dynamic parts)? I update the static binary to my repo on github, you can download and try, we both tested with real hardware and qemu-loongarch64 user mode is ok. This mksh built with gcc 13.2.1, binutils 2.42, linux 6.6.15 in the loongarch environment. https://github.com/lixing-star/binarys > Statically linked mksh from me is here: > https://debug.openadk.org/mksh we've tested your binary on 3c5000 is ok, but hanged with qemu-loongarch64. Are you cross compiled the mksh for use? > > best regards > Waldemar > best reards, XingLi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-13 1:42 ` lixing @ 2024-03-13 14:45 ` Waldemar Brodkorb 2024-03-13 14:52 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Waldemar Brodkorb @ 2024-03-13 14:45 UTC (permalink / raw) To: musl Hi, lixing wrote, > > 在 2024/3/13 上午1:18, Waldemar Brodkorb 写道: > > Hi Thorsten, > > Thorsten Glaser wrote, > > > > > Waldemar Brodkorb dixit: > > > > > > > lixing wrote, > > > > > We've tested static and dynamic build mksh with commit id > > > > > cbb8a0196aab53165a35339fd91ade599d184f both works ok. > > > That’s great to hear! > > > > > > > Can you check with qemu-system-loongarch64? I use gcc 13.2.0, > > > > binutils 2.42 and Linux 6.6.18 with the defconfig provided. > > > > Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? > > I just only use qemu user mode, but my colleague give me the address for > download the EFI as follow > > https://github.com/lixianglai/LoongarchVirtFirmware. > > Also, can you post the qemu-system-loongarch64 startup command to me? > > > > Perhaps to distinguish between emulation/runtime and toolchain > > > faults you could send each other the mksh binaries (if statically > > > linked, otherwise probably them plus musl’s dynamic parts)? > > I update the static binary to my repo on github, you can download and try, > we both tested with real hardware > > and qemu-loongarch64 user mode is ok. This mksh built with gcc 13.2.1, > binutils 2.42, linux 6.6.15 in the loongarch environment. > > https://github.com/lixing-star/binarys > > > Statically linked mksh from me is here: > > https://debug.openadk.org/mksh > we've tested your binary on 3c5000 is ok, but hanged with > qemu-loongarch64. Are you cross compiled the mksh for use? Yes I do. I found the reason why my mksh didn't worked. I compiled everything with -Os and then I get the deadlock. When I compile everything with -O2 musl mksh is working. So it seems some gcc problem code compiled with -Os. best regards Waldemar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-13 14:45 ` Waldemar Brodkorb @ 2024-03-13 14:52 ` Rich Felker 2024-03-14 5:44 ` Waldemar Brodkorb 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2024-03-13 14:52 UTC (permalink / raw) To: Waldemar Brodkorb; +Cc: musl On Wed, Mar 13, 2024 at 03:45:31PM +0100, Waldemar Brodkorb wrote: > Hi, > lixing wrote, > > > > > 在 2024/3/13 上午1:18, Waldemar Brodkorb 写道: > > > Hi Thorsten, > > > Thorsten Glaser wrote, > > > > > > > Waldemar Brodkorb dixit: > > > > > > > > > lixing wrote, > > > > > > We've tested static and dynamic build mksh with commit id > > > > > > cbb8a0196aab53165a35339fd91ade599d184f both works ok. > > > > That’s great to hear! > > > > > > > > > Can you check with qemu-system-loongarch64? I use gcc 13.2.0, > > > > > binutils 2.42 and Linux 6.6.18 with the defconfig provided. > > > > > Qemu is also 8.2.2. Can you provide your QEMU_EFI.fd for download? > > > > I just only use qemu user mode, but my colleague give me the address for > > download the EFI as follow > > > > https://github.com/lixianglai/LoongarchVirtFirmware. > > > > Also, can you post the qemu-system-loongarch64 startup command to me? > > > > > > Perhaps to distinguish between emulation/runtime and toolchain > > > > faults you could send each other the mksh binaries (if statically > > > > linked, otherwise probably them plus musl’s dynamic parts)? > > > > I update the static binary to my repo on github, you can download and try, > > we both tested with real hardware > > > > and qemu-loongarch64 user mode is ok. This mksh built with gcc 13.2.1, > > binutils 2.42, linux 6.6.15 in the loongarch environment. > > > > https://github.com/lixing-star/binarys > > > > > Statically linked mksh from me is here: > > > https://debug.openadk.org/mksh > > we've tested your binary on 3c5000 is ok, but hanged with > > qemu-loongarch64. Are you cross compiled the mksh for use? > > Yes I do. I found the reason why my mksh didn't worked. > I compiled everything with -Os and then I get the deadlock. > When I compile everything with -O2 musl mksh is working. > > So it seems some gcc problem code compiled with -Os. Let's look at the generated asm for the function using a_cas_p and see if this is a gcc bug or if the asm argument constraints as written allowed a transformation that's not actually valid. Rich ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-13 14:52 ` Rich Felker @ 2024-03-14 5:44 ` Waldemar Brodkorb 2024-03-14 6:45 ` lixing 0 siblings, 1 reply; 14+ messages in thread From: Waldemar Brodkorb @ 2024-03-14 5:44 UTC (permalink / raw) To: musl; +Cc: Waldemar Brodkorb Hi, Rich Felker wrote, > > Yes I do. I found the reason why my mksh didn't worked. > > I compiled everything with -Os and then I get the deadlock. > > When I compile everything with -O2 musl mksh is working. > > > > So it seems some gcc problem code compiled with -Os. > > Let's look at the generated asm for the function using a_cas_p and see > if this is a gcc bug or if the asm argument constraints as written > allowed a transformation that's not actually valid. Broken mksh with -Os: 000000012003b970 <cgt_init>: 12003b970: 02ff8063 addi.d $sp, $sp, -32 12003b974: 29c02077 st.d $s0, $sp, 8 12003b978: 27000078 stptr.d $s1, $sp, 0 12003b97c: 00150097 move $s0, $a0 12003b980: 001500b8 move $s1, $a1 12003b984: 1a000084 pcalau12i $a0, 4 12003b988: 1a000085 pcalau12i $a1, 4 12003b98c: 29c04076 st.d $fp, $sp, 16 12003b990: 29c06061 st.d $ra, $sp, 24 12003b994: 02c08076 addi.d $fp, $sp, 32 12003b998: 02c060a5 addi.d $a1, $a1, 24 12003b99c: 02c0c084 addi.d $a0, $a0, 48 12003b9a0: 54021400 bl 532 # 12003bbb4 <__vdsosym> 12003b9a4: 0015008e move $t2, $a0 12003b9a8: 38720000 dbar 0x0 12003b9ac: 1a00002d pcalau12i $t1, 1 12003b9b0: 1a00032f pcalau12i $t3, 25 12003b9b4: 02e5c1ad addi.d $t1, $t1, -1680 12003b9b8: 02ca21ec addi.d $t0, $t3, 648 12003b9bc: 2200018c ll.d $t0, $t0, 0 12003b9c0: 5c00198d bne $t0, $t1, 24 # 12003b9d8 <cgt_init+0x68> 12003b9c4: 001501cc move $t0, $t2 12003b9c8: 02ca21f0 addi.d $t4, $t3, 648 12003b9cc: 2300020c sc.d $t0, $t4, 0 12003b9d0: 0040818c slli.w $t0, $t0, 0x0 12003b9d4: 43ffe59f beqz $t0, -28 # 12003b9b8 <cgt_init+0x48> 12003b9d8: 38720000 dbar 0x0 12003b9dc: 400025c0 beqz $t2, 36 # 12003ba00 <cgt_init+0x90> 12003b9e0: 28c04076 ld.d $fp, $sp, 16 12003b9e4: 28c06061 ld.d $ra, $sp, 24 12003b9e8: 00150305 move $a1, $s1 12003b9ec: 001502e4 move $a0, $s0 12003b9f0: 26000078 ldptr.d $s1, $sp, 0 12003b9f4: 28c02077 ld.d $s0, $sp, 8 12003b9f8: 02c08063 addi.d $sp, $sp, 32 12003b9fc: 4c0001c0 jr $t2 12003ba00: 28c06061 ld.d $ra, $sp, 24 12003ba04: 28c04076 ld.d $fp, $sp, 16 12003ba08: 28c02077 ld.d $s0, $sp, 8 12003ba0c: 26000078 ldptr.d $s1, $sp, 0 12003ba10: 02bf6804 li.w $a0, -38 12003ba14: 02c08063 addi.d $sp, $sp, 32 12003ba18: 4c000020 ret Working mksh with -O2: 0000000120045f50 <cgt_init>: 120045f50: 02ff8063 addi.d $sp, $sp, -32 120045f54: 29c02077 st.d $s0, $sp, 8 120045f58: 27000078 stptr.d $s1, $sp, 0 120045f5c: 00150097 move $s0, $a0 120045f60: 001500b8 move $s1, $a1 120045f64: 1a000084 pcalau12i $a0, 4 120045f68: 1a000085 pcalau12i $a1, 4 120045f6c: 29c04076 st.d $fp, $sp, 16 120045f70: 29c06061 st.d $ra, $sp, 24 120045f74: 02c08076 addi.d $fp, $sp, 32 120045f78: 02dbc0a5 addi.d $a1, $a1, 1776 120045f7c: 02dc2084 addi.d $a0, $a0, 1800 120045f80: 54024c00 bl 588 # 1200461cc <__vdsosym> 120045f84: 0015008f move $t3, $a0 120045f88: 38720000 dbar 0x0 120045f8c: 1a000030 pcalau12i $t4, 1 120045f90: 1a00036d pcalau12i $t1, 27 120045f94: 02fd4210 addi.d $t4, $t4, -176 120045f98: 50001400 b 20 # 120045fac <cgt_init+0x5c> 120045f9c: 02ca21ae addi.d $t2, $t1, 648 120045fa0: 230001cc sc.d $t0, $t2, 0 120045fa4: 0040818c slli.w $t0, $t0, 0x0 120045fa8: 44001580 bnez $t0, 20 # 120045fbc <cgt_init+0x6c> 120045fac: 02ca21ac addi.d $t0, $t1, 648 120045fb0: 2200018e ll.d $t2, $t0, 0 120045fb4: 001501ec move $t0, $t3 120045fb8: 5bffe60e beq $t4, $t2, -28 # 120045f9c <cgt_init+0x4c> 120045fbc: 38720000 dbar 0x0 120045fc0: 400025e0 beqz $t3, 36 # 120045fe4 <cgt_init+0x94> 120045fc4: 28c04076 ld.d $fp, $sp, 16 120045fc8: 28c06061 ld.d $ra, $sp, 24 120045fcc: 00150305 move $a1, $s1 120045fd0: 001502e4 move $a0, $s0 120045fd4: 26000078 ldptr.d $s1, $sp, 0 120045fd8: 28c02077 ld.d $s0, $sp, 8 120045fdc: 02c08063 addi.d $sp, $sp, 32 120045fe0: 4c0001e0 jr $t3 120045fe4: 28c06061 ld.d $ra, $sp, 24 120045fe8: 28c04076 ld.d $fp, $sp, 16 120045fec: 28c02077 ld.d $s0, $sp, 8 120045ff0: 26000078 ldptr.d $s1, $sp, 0 120045ff4: 02bf6804 li.w $a0, -38 120045ff8: 02c08063 addi.d $sp, $sp, 32 120045ffc: 4c000020 ret Does that help? Both binaries can be found on https://debug.openadk.org. best regards Waldemar ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-14 5:44 ` Waldemar Brodkorb @ 2024-03-14 6:45 ` lixing 2024-03-14 13:44 ` Leah Neukirchen 0 siblings, 1 reply; 14+ messages in thread From: lixing @ 2024-03-14 6:45 UTC (permalink / raw) To: musl 在 2024/3/14 下午1:44, Waldemar Brodkorb 写道: > Hi, > Rich Felker wrote, > >>> Yes I do. I found the reason why my mksh didn't worked. >>> I compiled everything with -Os and then I get the deadlock. >>> When I compile everything with -O2 musl mksh is working. >>> >>> So it seems some gcc problem code compiled with -Os. >> Let's look at the generated asm for the function using a_cas_p and see >> if this is a gcc bug or if the asm argument constraints as written >> allowed a transformation that's not actually valid. > Broken mksh with -Os: > > 000000012003b970 <cgt_init>: > 12003b970: 02ff8063 addi.d $sp, $sp, -32 > 12003b974: 29c02077 st.d $s0, $sp, 8 > 12003b978: 27000078 stptr.d $s1, $sp, 0 > 12003b97c: 00150097 move $s0, $a0 > 12003b980: 001500b8 move $s1, $a1 > 12003b984: 1a000084 pcalau12i $a0, 4 > 12003b988: 1a000085 pcalau12i $a1, 4 > 12003b98c: 29c04076 st.d $fp, $sp, 16 > 12003b990: 29c06061 st.d $ra, $sp, 24 > 12003b994: 02c08076 addi.d $fp, $sp, 32 > 12003b998: 02c060a5 addi.d $a1, $a1, 24 > 12003b99c: 02c0c084 addi.d $a0, $a0, 48 > 12003b9a0: 54021400 bl 532 # 12003bbb4 <__vdsosym> > 12003b9a4: 0015008e move $t2, $a0 > 12003b9a8: 38720000 dbar 0x0 > 12003b9ac: 1a00002d pcalau12i $t1, 1 > 12003b9b0: 1a00032f pcalau12i $t3, 25 > 12003b9b4: 02e5c1ad addi.d $t1, $t1, -1680 > 12003b9b8: 02ca21ec addi.d $t0, $t3, 648 > 12003b9bc: 2200018c ll.d $t0, $t0, 0 > 12003b9c0: 5c00198d bne $t0, $t1, 24 # 12003b9d8 <cgt_init+0x68> > 12003b9c4: 001501cc move $t0, $t2 > 12003b9c8: 02ca21f0 addi.d $t4, $t3, 648 > 12003b9cc: 2300020c sc.d $t0, $t4, 0 > 12003b9d0: 0040818c slli.w $t0, $t0, 0x0 > 12003b9d4: 43ffe59f beqz $t0, -28 # 12003b9b8 <cgt_init+0x48> > 12003b9d8: 38720000 dbar 0x0 > 12003b9dc: 400025c0 beqz $t2, 36 # 12003ba00 <cgt_init+0x90> > 12003b9e0: 28c04076 ld.d $fp, $sp, 16 > 12003b9e4: 28c06061 ld.d $ra, $sp, 24 > 12003b9e8: 00150305 move $a1, $s1 > 12003b9ec: 001502e4 move $a0, $s0 > 12003b9f0: 26000078 ldptr.d $s1, $sp, 0 > 12003b9f4: 28c02077 ld.d $s0, $sp, 8 > 12003b9f8: 02c08063 addi.d $sp, $sp, 32 > 12003b9fc: 4c0001c0 jr $t2 > 12003ba00: 28c06061 ld.d $ra, $sp, 24 > 12003ba04: 28c04076 ld.d $fp, $sp, 16 > 12003ba08: 28c02077 ld.d $s0, $sp, 8 > 12003ba0c: 26000078 ldptr.d $s1, $sp, 0 > 12003ba10: 02bf6804 li.w $a0, -38 > 12003ba14: 02c08063 addi.d $sp, $sp, 32 > 12003ba18: 4c000020 ret > > Working mksh with -O2: > 0000000120045f50 <cgt_init>: > 120045f50: 02ff8063 addi.d $sp, $sp, -32 > 120045f54: 29c02077 st.d $s0, $sp, 8 > 120045f58: 27000078 stptr.d $s1, $sp, 0 > 120045f5c: 00150097 move $s0, $a0 > 120045f60: 001500b8 move $s1, $a1 > 120045f64: 1a000084 pcalau12i $a0, 4 > 120045f68: 1a000085 pcalau12i $a1, 4 > 120045f6c: 29c04076 st.d $fp, $sp, 16 > 120045f70: 29c06061 st.d $ra, $sp, 24 > 120045f74: 02c08076 addi.d $fp, $sp, 32 > 120045f78: 02dbc0a5 addi.d $a1, $a1, 1776 > 120045f7c: 02dc2084 addi.d $a0, $a0, 1800 > 120045f80: 54024c00 bl 588 # 1200461cc <__vdsosym> > 120045f84: 0015008f move $t3, $a0 > 120045f88: 38720000 dbar 0x0 > 120045f8c: 1a000030 pcalau12i $t4, 1 > 120045f90: 1a00036d pcalau12i $t1, 27 > 120045f94: 02fd4210 addi.d $t4, $t4, -176 > 120045f98: 50001400 b 20 # 120045fac <cgt_init+0x5c> > 120045f9c: 02ca21ae addi.d $t2, $t1, 648 > 120045fa0: 230001cc sc.d $t0, $t2, 0 > 120045fa4: 0040818c slli.w $t0, $t0, 0x0 > 120045fa8: 44001580 bnez $t0, 20 # 120045fbc <cgt_init+0x6c> > 120045fac: 02ca21ac addi.d $t0, $t1, 648 > 120045fb0: 2200018e ll.d $t2, $t0, 0 > 120045fb4: 001501ec move $t0, $t3 > 120045fb8: 5bffe60e beq $t4, $t2, -28 # 120045f9c <cgt_init+0x4c> > 120045fbc: 38720000 dbar 0x0 > 120045fc0: 400025e0 beqz $t3, 36 # 120045fe4 <cgt_init+0x94> > 120045fc4: 28c04076 ld.d $fp, $sp, 16 > 120045fc8: 28c06061 ld.d $ra, $sp, 24 > 120045fcc: 00150305 move $a1, $s1 > 120045fd0: 001502e4 move $a0, $s0 > 120045fd4: 26000078 ldptr.d $s1, $sp, 0 > 120045fd8: 28c02077 ld.d $s0, $sp, 8 > 120045fdc: 02c08063 addi.d $sp, $sp, 32 > 120045fe0: 4c0001e0 jr $t3 > 120045fe4: 28c06061 ld.d $ra, $sp, 24 > 120045fe8: 28c04076 ld.d $fp, $sp, 16 > 120045fec: 28c02077 ld.d $s0, $sp, 8 > 120045ff0: 26000078 ldptr.d $s1, $sp, 0 > 120045ff4: 02bf6804 li.w $a0, -38 > 120045ff8: 02c08063 addi.d $sp, $sp, 32 > 120045ffc: 4c000020 ret > > Does that help? Both binaries can be found on https://debug.openadk.org. > > best regards > Waldemar we checked the objdump binaries for -Os and -O2, the a_cas_p implement looks ok for both. Also, we cross build the musl and mksh with -Os, the binary hang with qemu user mode emulation , but not hang in the real hardware. so, maybe this is a qemu problem, we will let our qemu guys to check this problem. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-14 6:45 ` lixing @ 2024-03-14 13:44 ` Leah Neukirchen 2024-03-15 0:58 ` lixing 0 siblings, 1 reply; 14+ messages in thread From: Leah Neukirchen @ 2024-03-14 13:44 UTC (permalink / raw) To: lixing; +Cc: musl lixing <lixing@loongson.cn> writes: > we checked the objdump binaries for -Os and -O2, the a_cas_p implement > looks ok for both. > > Also, we cross build the musl and mksh with -Os, the binary hang with > qemu user mode emulation , but not hang in the real hardware. > > so, maybe this is a qemu problem, we will let our qemu guys to check > this problem. Pretty surely it's a bug in QEMU. qemu 8.1.5 works with mksh.Os, qemu 8.2.1 hangs. I have bisected the issue down to: commit c5af6628f4be5d30800233e59ba3842ca19a12e6 (HEAD) Author: Jiajie Chen <c@jia.je> Date: Tue Aug 22 09:13:52 2023 +0200 target/loongarch: Extract make_address_i() helper Reverting this hunk fixes it: diff --git a/target/loongarch/insn_trans/trans_atomic.c.inc b/target/loongarch/insn_trans/trans_atomic.c.inc index fbc081448d..bff3e7a74c 100644 --- a/target/loongarch/insn_trans/trans_atomic.c.inc +++ b/target/loongarch/insn_trans/trans_atomic.c.inc @@ -7,8 +7,9 @@ static bool gen_ll(DisasContext *ctx, arg_rr_i *a, MemOp mop) { TCGv dest = gpr_dst(ctx, a->rd, EXT_NONE); TCGv src1 = gpr_src(ctx, a->rj, EXT_NONE); - TCGv t0 = make_address_i(ctx, src1, a->imm); + TCGv t0 = tcg_temp_new(); + tcg_gen_addi_tl(t0, src1, a->imm); tcg_gen_qemu_ld_i64(dest, t0, ctx->mem_idx, mop); tcg_gen_st_tl(t0, cpu_env, offsetof(CPULoongArchState, lladdr)); tcg_gen_st_tl(dest, cpu_env, offsetof(CPULoongArchState, llval)); I think the issue is that make_address_i optimizes the addition away if a->imm is zero, but that's just from looking at the code for 15min. hth, -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-14 13:44 ` Leah Neukirchen @ 2024-03-15 0:58 ` lixing 0 siblings, 0 replies; 14+ messages in thread From: lixing @ 2024-03-15 0:58 UTC (permalink / raw) To: Leah Neukirchen; +Cc: musl 在 2024/3/14 下午9:44, Leah Neukirchen 写道: > lixing <lixing@loongson.cn> writes: > >> we checked the objdump binaries for -Os and -O2, the a_cas_p implement >> looks ok for both. >> >> Also, we cross build the musl and mksh with -Os, the binary hang with >> qemu user mode emulation , but not hang in the real hardware. >> >> so, maybe this is a qemu problem, we will let our qemu guys to check >> this problem. > Pretty surely it's a bug in QEMU. qemu 8.1.5 works with mksh.Os, > qemu 8.2.1 hangs. I have bisected the issue down to: > > commit c5af6628f4be5d30800233e59ba3842ca19a12e6 (HEAD) > Author: Jiajie Chen <c@jia.je> > Date: Tue Aug 22 09:13:52 2023 +0200 > > target/loongarch: Extract make_address_i() helper > > Reverting this hunk fixes it: > > diff --git a/target/loongarch/insn_trans/trans_atomic.c.inc b/target/loongarch/insn_trans/trans_atomic.c.inc > index fbc081448d..bff3e7a74c 100644 > --- a/target/loongarch/insn_trans/trans_atomic.c.inc > +++ b/target/loongarch/insn_trans/trans_atomic.c.inc > @@ -7,8 +7,9 @@ static bool gen_ll(DisasContext *ctx, arg_rr_i *a, MemOp mop) > { > TCGv dest = gpr_dst(ctx, a->rd, EXT_NONE); > TCGv src1 = gpr_src(ctx, a->rj, EXT_NONE); > - TCGv t0 = make_address_i(ctx, src1, a->imm); > + TCGv t0 = tcg_temp_new(); > > + tcg_gen_addi_tl(t0, src1, a->imm); > tcg_gen_qemu_ld_i64(dest, t0, ctx->mem_idx, mop); > tcg_gen_st_tl(t0, cpu_env, offsetof(CPULoongArchState, lladdr)); > tcg_gen_st_tl(dest, cpu_env, offsetof(CPULoongArchState, llval)); > > I think the issue is that make_address_i optimizes the addition away > if a->imm is zero, but that's just from looking at the code for 15min. > > hth, Our qemu guys debuged the binary find that "ll.d $t0, $t0, 0" make the t0 reg turn to 0,that should be the qemu code problem. thanks. XingLi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [musl] loongarch64 atomics not working? 2024-03-12 2:06 ` Hongliang Wang 2024-03-12 8:31 ` lixing @ 2024-03-12 8:48 ` Jingyun Hua 1 sibling, 0 replies; 14+ messages in thread From: Jingyun Hua @ 2024-03-12 8:48 UTC (permalink / raw) To: musl Hi, I'm working on alpine loongarch64 port. I installed alpine iso on the loongarch64 physical machine and compiled mksh 59c. All tests passed: pass ./check.t:debian-117-1 pass ./check.t:debian-117-2 pass ./check.t:debian-117-3 pass ./check.t:debian-117-4 pass ./check.t:case-zsh pass ./check.t:case-braces pass ./check.t:command-shift pass ./check.t:command-set pass ./check.t:command-readonly pass ./check.t:command-dot-regression pass ./check.t:command-pvV-posix-priorities pass ./check.t:duffs-device pass ./check.t:stateptr-underflow pass ./check.t:xtrace-1 pass ./check.t:xtrace-2 pass ./check.t:fksh-flags pass ./check.t:fsh-flags Total failed: 0 Total passed: 530 >>> mksh: Entering fakeroot... >>> mksh-doc*: Running split function doc... >>> mksh-doc*: Preparing subpackage mksh-doc... >>> mksh-doc*: Running postcheck for mksh-doc >>> mksh*: Running postcheck for mksh Regards, Jingyun Hua On 3/12/24 10:06 AM, Hongliang Wang wrote: > > > 在 2024/3/12 上午8:51, Rich Felker 写道: >> There's been a report of mksh hanging on loongarch64, at least under >> qemu, apparently hanging in a_cas_p: >> >> (gdb) run >> Starting program: /mksh >> ^C >> Program received signal SIGINT, Interrupt. >> a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, >> s=0x7fffffffc34c) >> at ./src/internal/atomic.h:94 >> warning: 94 ./src/internal/atomic.h: No such file or directory >> (gdb) bt >> #0 a_cas_p (p=0x120054288 <vdso_func>, t=0x12003b970 <cgt_init>, >> s=0x7fffffffc34c) at ./src/internal/atomic.h:94 >> #1 cgt_init (clk=0, ts=0x7ffffffefb60) at src/time/clock_gettime.c:51 >> #2 0x000000012003ba4c in __clock_gettime (clk=clk@entry=0, >> ts=ts@entry=0x7ffffffefb60) at src/time/clock_gettime.c:67 >> #3 0x000000012003830c in gettimeofday (tv=tv@entry=0x7ffffffefba0, >> tz=tz@entry=0x0) at src/time/gettimeofday.c:9 >> #4 0x000000012002f098 in change_winsz () at var.c:1718 >> #5 0x0000000120000348 in main_init (lp=<synthetic pointer>, >> sp=<synthetic pointer>, argv=0x7ffffffefd18, argc=1) at main.c:369 >> #6 main (argc=<optimized out>, argv=<optimized out>) at main.c:738 >> >> This is very basic usage, just the vdso clock_gettime init code trying >> to replace a pointer atomically. Is it working on real hardware? I'm >> trying to figure out if this is a qemu bug, or if the asm or the asm >> argument constraints are wrong in musl's >> arch/loongarch64/atomic_arch.h. >> >> Rich >> > > We will test it on real hardware to confirm if it can work as soon as > possible. > > Regards, > Hongliang Wang -- Jingyun Hua ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-03-15 0:59 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-12 0:51 [musl] loongarch64 atomics not working? Rich Felker 2024-03-12 2:06 ` Hongliang Wang 2024-03-12 8:31 ` lixing 2024-03-12 16:18 ` Waldemar Brodkorb 2024-03-12 16:47 ` Thorsten Glaser 2024-03-12 17:18 ` Waldemar Brodkorb 2024-03-13 1:42 ` lixing 2024-03-13 14:45 ` Waldemar Brodkorb 2024-03-13 14:52 ` Rich Felker 2024-03-14 5:44 ` Waldemar Brodkorb 2024-03-14 6:45 ` lixing 2024-03-14 13:44 ` Leah Neukirchen 2024-03-15 0:58 ` lixing 2024-03-12 8:48 ` Jingyun Hua
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).