[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Mar 2024 16:48:41 +0800
From: Jingyun Hua <huajingyun@...ngson.cn>
To: musl@...ts.openwall.com
Subject: Re: loongarch64 atomics not working?
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@...ry=0,
>> ts=ts@...ry=0x7ffffffefb60) at src/time/clock_gettime.c:67
>> #3 0x000000012003830c in gettimeofday (tv=tv@...ry=0x7ffffffefba0,
>> tz=tz@...ry=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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
