Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4aa35a13-387b-ca91-1d8b-cc74f01f9920@loongson.cn>
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.