Re: [musl] loongarch64 atomics not working?

[Rich Felker <dalias@libc.org>]

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