[musl] loongarch64 atomics not working?

[musl] loongarch64 atomics not working?

[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

Re: [musl] loongarch64 atomics not working?

[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

Re: [musl] loongarch64 atomics not working?

[lixing]

在 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

Re: [musl] loongarch64 atomics not working?

[Jingyun Hua]

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

Re: [musl] loongarch64 atomics not working?

[Waldemar Brodkorb]

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

Re: [musl] loongarch64 atomics not working?

[Thorsten Glaser]

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

Re: [musl] loongarch64 atomics not working?

[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?
> 
> 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
 

Re: [musl] loongarch64 atomics not working?

[lixing]

在 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

Re: [musl] loongarch64 atomics not working?

[Waldemar Brodkorb]

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

Re: [musl] loongarch64 atomics not working?

[Rich Felker]

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

Re: [musl] loongarch64 atomics not working?

[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

Re: [musl] loongarch64 atomics not working?

[lixing]

在 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.

Re: [musl] loongarch64 atomics not working?

[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,
-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

Re: [musl] loongarch64 atomics not working?

[lixing]

在 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