[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Apr 2020 17:44:07 -0500
From: <sidneym@...eaurora.org>
To: <musl@...ts.openwall.com>
Subject: RE: Hexagon DSP support
> -----Original Message-----
> From: 'Rich Felker' <dalias@...c.org>
> Sent: Wednesday, April 15, 2020 2:30 PM
> To: sidneym@...eaurora.org
> Cc: musl@...ts.openwall.com
> Subject: Re: [musl] Hexagon DSP support
>
> On Wed, Apr 15, 2020 at 02:12:12PM -0500, sidneym@...eaurora.org wrote:
> > src/api/ftw.c:44:1: error: switch condition has boolean value
> > [-Werror,-Wswitch-bool]
>
> Compiling libc-test with -Werror is invalid. It necessarily must produce
some
> warnings, and needs to be able to distinguish actual errors from them.
>
> > 8 errors generated.
> > src/functional/dlopen.c:39: dlsym main failed: Symbol not found: main
> > FAIL src/functional/dlopen.exe [status 1]
> > clang-11: warning: argument unused during compilation: '-rdynamic'
> > [-Wunused-command-line-argument]
>
> This is a clang deficiency that's preventing the test from working.
>
> > src/functional/ipc_msg.c:62: qid_ds.msg_lspid == 0 failed: got 100,
> > want 0
> > src/functional/ipc_msg.c:64: (long long)qid_ds.msg_stime == 0 failed:
> > got 6815993655711498240, want 0
> > src/functional/ipc_msg.c:67: qid_ds.msg_ctime >= t failed: got
> > 70368744177664, want >= 154502684032321054
> > src/functional/ipc_msg.c:71: qid_ds.msg_qbytes > 0 failed: got 0, want
> > > 0
> > src/functional/ipc_msg.c:76: qid_ds.msg_qnum == 1 failed: got 0, want
> > 1
> > src/functional/ipc_msg.c:77: qid_ds.msg_lspid == getpid() failed: got
> > 100, want 185819
> > src/functional/ipc_msg.c:81: msg_stime is 6815993655711498240 want <=
> > 154502684032321059
> > src/functional/ipc_msg.c:128: child exit status: 256 FAIL
> > src/functional/ipc_msg-static.exe [status 1]
>
> This is the sysvipc bits headers issue I mentioned. Same with the sem/shm
> ones.
Passing with updated headers and qemu.
>
> > src/functional/pthread_mutex.c:145: PTHREAD_MUTEX_ERRORCHECK relock
> > did not return EDEADLK, got deadlock
> > src/functional/pthread_mutex.c:148: PTHREAD_MUTEX_RECURSIVE relock
> did
> > not succed, got deadlock FAIL src/functional/pthread_mutex-static.exe
> > [status 1]
> > src/functional/pthread_mutex.c:145: PTHREAD_MUTEX_ERRORCHECK relock
> > did not return EDEADLK, got
> > src/functional/pthread_mutex.c:148: PTHREAD_MUTEX_RECURSIVE relock
> did
> > not succed, got deadlock FAIL src/functional/pthread_mutex.exe [status
> > 1]
>
> This suggests broken atomics. It doesn't look like anything qemu-user
could
> cause (unless it's just failing to emulate the atomics at all).
>
Updated QEMU to include time64 changes. Passing now.
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:148: PTHREAD_MUTEX_ERRORCHECK
> relock
> > did not return EDEADLK, got deadlock
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented FAIL
> > src/functional/pthread_mutex_pi-static.exe [timed out]
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:148: PTHREAD_MUTEX_ERRORCHECK
> relock
> > did not return EDEADLK, got deadlock
> > src/functional/pthread_mutex_pi.c:42:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:151: PTHREAD_MUTEX_RECURSIVE
> relock
> > did not succed, got deadlock
> > src/functional/pthread_mutex_pi.c:87:
> > pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT) failed:
> > Function not implemented
> > src/functional/pthread_mutex_pi.c:24: pthread_mutex_unlock(a[0])
> > failed: Operation not permitted FAIL
> > src/functional/pthread_mutex_pi.exe [signal Segmentation fault]
> > src/functional/pthread_robust.c:39:
> > pthread_mutexattr_setrobust(&mtx_a, PTHREAD_MUTEX_ROBUST) failed:
> > (pshared==0, pi==0) Function not implemented (setting robust
> > attribute) FAIL src/functional/pthread_robust-static.exe [timed out]
> > src/functional/pthread_robust.c:39:
> > pthread_mutexattr_setrobust(&mtx_a, PTHREAD_MUTEX_ROBUST) failed:
> > (pshared==0, pi==0) Function not implemented (setting robust
> > attribute) FAIL src/functional/pthread_robust.exe [timed out]
>
> These are all expected on qemu-user: kernel prio-inherit and robust
features
> are not emulated by qemu.
>
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:49: sem value should be 0, got 3 FAIL
> > src/functional/sem_init-static.exe [status 1]
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:19: sem_timedwait(s+1, &ts) failed:
> > Operation timed out
> > src/functional/sem_init.c:49: sem value should be 0, got 3 FAIL
> > src/functional/sem_init.exe [status 1]
>
> This is probably broken atomics again.
Passed with updated headers and QEMU.
>
> > src/functional/strptime.c:23: "%F": failed to parse "1856-07-10"
> > src/functional/strptime.c:23: "%s": failed to parse "683078400"
> > src/functional/strptime.c:47: "%z": failed to parse "+0200"
> > src/functional/strptime.c:47: "%z": failed to parse "-0530"
> > src/functional/strptime.c:47: "%z": failed to parse "-06"
> > FAIL src/functional/strptime-static.exe [status 1]
> > src/functional/strptime.c:23: "%F": failed to parse "1856-07-10"
> > src/functional/strptime.c:23: "%s": failed to parse "683078400"
> > src/functional/strptime.c:47: "%z": failed to parse "+0200"
> > src/functional/strptime.c:47: "%z": failed to parse "-0530"
> > src/functional/strptime.c:47: "%z": failed to parse "-06"
> > FAIL src/functional/strptime.exe [status 1]
>
> These are expected, functionality musl does not yet support
(future-standard, I
> think).
>
> > src/functional/utime.c:38: st.st_atim.tv_sec == 0 failed: 1
> > src/functional/utime.c:40: st.st_mtim.tv_sec == 0 failed: 1073741822
> > src/functional/utime.c:47: st.st_atim.tv_sec >= t failed: 0
> > src/functional/utime.c:48: st.st_mtim.tv_sec == 0 failed: 1073741823
> > src/functional/utime.c:55: st.st_mtim.tv_sec >= t failed: 1073741822
> > src/functional/utime.c:59: st.st_atim.tv_sec >= t failed: 0
> > src/functional/utime.c:60: st.st_mtim.tv_sec >= t failed: 1073741823
> > src/functional/utime.c:65: st.st_atim.tv_sec == 1LL<<32 failed: 0
> > src/functional/utime.c:66: st.st_mtim.tv_sec == 1LL<<32 failed: 0 FAIL
> > src/functional/utime-static.exe [status 1]
> > src/functional/utime.c:38: st.st_atim.tv_sec == 0 failed: 1
> > src/functional/utime.c:40: st.st_mtim.tv_sec == 0 failed: 1073741822
> > src/functional/utime.c:47: st.st_atim.tv_sec >= t failed: 0
> > src/functional/utime.c:48: st.st_mtim.tv_sec == 0 failed: 1073741823
> > src/functional/utime.c:55: st.st_mtim.tv_sec >= t failed: 1073741822
> > src/functional/utime.c:59: st.st_atim.tv_sec >= t failed: 0
> > src/functional/utime.c:60: st.st_mtim.tv_sec >= t failed: 1073741823
> > src/functional/utime.c:65: st.st_atim.tv_sec == 1LL<<32 failed: 0
> > src/functional/utime.c:66: st.st_mtim.tv_sec == 1LL<<32 failed: 0 FAIL
> > src/functional/utime.exe [status 1]
>
> Looks like something is wrong here, possibly wrong struct kstat, or it
could be a
> qemu bug.
It seems like QEMU's TARGET_NR_utimensat needs to changes similar to those
done for clock_get/settime to account for 64bit time_t. I made some
changes but the last 2 checks at 65 and 66 still fail.
>
> > src/math/ucb/sqrt.h:47: bad fp exception: RN
> > sqrt(0x1.fffffffffffffp+1023)=0x1.fffffffffffffp+511, want INEXACT got
> > 0 [...]
> > src/math/special/sqrt.h:74: bad fp exception: RN
> > sqrtl(0x1.9b294f88p-1015)=0x1.cad197e28e85bp-508, want INEXACT got 0
> > FAIL src/math/sqrtl.exe [status 1]
>
> These are likely all general (not arch-specific) clang floating point
bugs. We
> should see if they also happen compiling other archs without asm versions
of
> sqrt.
Assembly version of sqrt does pass.
>
> Alternatively it might be a qemu fpu emulation bug. I've seen this kind of
thing
> (inconsistent across arch) on other archs under qemu-user.
>
> > src/regression/malloc-brk-fail.c:41: malloc(10000) failed (eventhough
> > 64k is available to mmap): Out of memory FAIL
> > src/regression/malloc-brk-fail-static.exe [status 1] FAIL
> > src/regression/malloc-brk-fail.exe [timed out]
>
> This test does not seem to work on modern kernels much less qemu-user.
>
> > src/regression/pthread-robust-detach.c:33:
> pthread_mutexattr_setrobust(&mtx_a, 1) failed: (pshared==0) got 38
> "Function not implemented" want 0 "No error information"
> > src/regression/pthread-robust-detach.c:50: pthread_mutex_timedlock(&mtx,
> &ts) failed: (pshared==0) got 110 "Operation timed out" want 130 "Previous
> owner died"
> > src/regression/pthread-robust-detach.c:33:
> pthread_mutexattr_setrobust(&mtx_a, 1) failed: (pshared==1) got 38
> "Function not implemented" want 0 "No error information"
> > src/regression/pthread-robust-detach.c:50: pthread_mutex_timedlock(&mtx,
> &ts) failed: (pshared==1) got 110 "Operation timed out" want 130 "Previous
> owner died"
> > FAIL src/regression/pthread-robust-detach-static.exe [status 1]
> > src/regression/pthread-robust-detach.c:33:
> pthread_mutexattr_setrobust(&mtx_a, 1) failed: (pshared==0) got 38
> "Function not implemented" want 0 "No error information"
> > src/regression/pthread-robust-detach.c:50: pthread_mutex_timedlock(&mtx,
> &ts) failed: (pshared==0) got 110 "Operation timed out" want 130 "Previous
> owner died"
> > src/regression/pthread-robust-detach.c:33:
> pthread_mutexattr_setrobust(&mtx_a, 1) failed: (pshared==1) got 38
> "Function not implemented" want 0 "No error information"
> > src/regression/pthread-robust-detach.c:50: pthread_mutex_timedlock(&mtx,
> &ts) failed: (pshared==1) got 110 "Operation timed out" want 130 "Previous
> owner died"
> > FAIL src/regression/pthread-robust-detach.exe [status 1]
>
> Expected on qemu-user.
>
> > src/regression/pthread_cond-smasher.c:140: main thread in phase 0 (0
> > threads inside), finished waiting: Operation timed out FAIL
> > src/regression/pthread_cond-smasher-static.exe [status 1]
> > src/regression/pthread_cond-smasher.c:104: thread 5 in phase 0 (0)
> > finished waiting: Operation timed out FAIL
> > src/regression/pthread_cond-smasher.exe [status 1]
>
> These could be atomic bugs or just emulation being slow.
I bumped the timeout to 240 seconds it might have fixed these.
>
> > src/regression/pthread_cond_wait-cancel_ignored.c:52:
> > pthread_cond_wait did not act on cancellation FAIL
> > src/regression/pthread_cond_wait-cancel_ignored-static.exe [status 1]
> > src/regression/pthread_once-deadlock.c:41: sem_timedwait(s,&ts)
> > failed: Operation timed out
> > src/regression/pthread_once-deadlock.c:44: pthread_once deadlocked
> > FAIL src/regression/pthread_once-deadlock-static.exe [status 1]
>
> These are definitely atomic bugs (either in the arch bits or in qemu).
Also fixed, time64 change to QEMU was key to correcting a lot of these
issues.
>
> Rich
Hi,
Updated libc-test REPORT and musl patch are attached. I had to update QEMU,
pulling in 64bit time changes and routing the system calls to those
interfaces. The routing of the syscalls to the 64bit interfaces is not
committed but the patch for it is here:
https://github.com/qemu/qemu/commit/b792b073e1042ca2668adb57142efba838620329
The Hexagon branch of musl is here:
https://github.com/quic/musl/tree/hexagon
The sqrt routine I added is from compiler-rt.builtins and it is more
involved than other target's versions. I can see how sqrt might be excluded
from the c-library to keep the target specific complexity to a minimum.
Thanks,
Download attachment "winmail.dat" of type "application/ms-tnef" (274324 bytes)
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.
