From: Rich Felker <dalias@libc.org>
To: sidneym@codeaurora.org
Cc: musl@lists.openwall.com
Subject: Re: [musl] Hexagon DSP support
Date: Tue, 5 May 2020 20:59:29 -0400 [thread overview]
Message-ID: <20200506005929.GG21576@brightrain.aerifal.cx> (raw)
In-Reply-To: <8c3611dcf8e2c59885fecd9ebdc70d79@codeaurora.org>
On Tue, May 05, 2020 at 06:37:41PM -0500, sidneym@codeaurora.org wrote:
> >- The definitions in bits/msg.h, bits/sem.h, and bits/shm.h are not
> > time64-compatible. In fact bits/sem.h is a regression; you had it
> > right before and broke it.
> As you point out below the core of the problem was the missing time64
> calls. I've updated the structures to use what I hope or the
> correct types.
I think they're still wrong and you need to do like the existing
32-bit archs, defining IPC_STAT to 0x102 and putting separate unsigned
long *_lo/*_hi members in the right places for the kernel ABI and
adding the time_t members at the ends. This is almost surely the case
if _Alignof(long long) is 8 on hexagon, since the kernel's
include/uapi/asm-generic/msgbuf.h etc. have the lo/hi pairs misaligned
(struct ipc_perm is an odd number of 32-bit words). The fact that you
had to change qemu to make this work suggests that you still have it
wrong too -- you should not have to change qemu or the kernel to make
it work if you do it right.
> >- The definition in bits/stat.h is using the wrong types (you need to
> > use libc type names for all the members; this is a policy
> > requirement to ensure that none inadvertently mismatch). Note that
> > there's not even really a need to use an arch-specific header here
> > anymore; the kernel definition comes from arch/hexagon/kstat.h and
> > the bits/stat.h can just be copied from aarch64 or something else
> > with a clean layout.
>
> I used OpenRISC's stat.h.
Is there a reason? It has old __st_*tim32 members but you don't need
them since there's no old-musl-ABI involved.
> src/api/ftw.c:44:1: error: switch condition has boolean value [-Werror,-Wswitch-bool]
> C(S_ISBLK(0))
> ^~~~~~~~~~~~~
You're still building libc-test with -Werror which will give bogus
results.
> src/api/sys_ipc.c:13:1: error: initializing 'uid_t *' (aka 'unsigned int *') with an expression of type 'int *' converts between pointers to integer types with different sign [-Werror,-Wpointer-sign]
> F(uid_t,uid)
> ^~~~~~~~~~~~
> src/api/sys_ipc.c:3:20: note: expanded from macro 'F'
> #define F(t,n) {t *y = &x.n;}
> ^ ~~~~
This is happening because struct ipc_perm's members have the wrong
types (but I think you should just delete your bits/ipc.h because the
generic one is correct and matches the kernel's ABI for hexagon).
> src/functional/ipc_msg.c:63: qid_ds.msg_qnum == 0 failed: got 16384, want 0
> src/functional/ipc_msg.c:67: (long long)qid_ds.msg_rtime == 0 failed: got 6823500725968961536, want 0
> src/functional/ipc_msg.c:69: qid_ds.msg_ctime >= t failed: got 69713, want >= 1588720066
> src/functional/ipc_msg.c:73: qid_ds.msg_qbytes > 0 failed: got 0, want > 0
> src/functional/ipc_msg.c:78: qid_ds.msg_qnum == 1 failed: got 16384, want 1
> src/functional/ipc_msg.c:79: qid_ds.msg_lspid == getpid() failed: got 0, want 240818
> src/functional/ipc_msg.c:81: msg_stime is 0 want >= 1588720066
> src/functional/ipc_msg.c:130: child exit status: 256
> FAIL src/functional/ipc_msg-static.exe [status 1]
> src/functional/ipc_msg.c:63: qid_ds.msg_qnum == 0 failed: got 16384, want 0
> src/functional/ipc_msg.c:67: (long long)qid_ds.msg_rtime == 0 failed: got 6823500725968961536, want 0
> src/functional/ipc_msg.c:69: qid_ds.msg_ctime >= t failed: got 0, want >= 1588720066
> src/functional/ipc_msg.c:73: qid_ds.msg_qbytes > 0 failed: got 0, want > 0
> src/functional/ipc_msg.c:78: qid_ds.msg_qnum == 1 failed: got 16384, want 1
> src/functional/ipc_msg.c:79: qid_ds.msg_lspid == getpid() failed: got 0, want 240786
> src/functional/ipc_msg.c:81: msg_stime is 0 want >= 1588720066
> src/functional/ipc_msg.c:130: child exit status: 256
> FAIL src/functional/ipc_msg.exe [status 1]
These indicate your struct ipc_perm/msqid_ds mismatch kernel, as
described above.
Otherwise I didn't see anything obviously wrong in tests. Having less
noise from -Werror and the above issues would make it easier to review
the report though and ensure I'm not missing anything.
Rich
next prev parent reply other threads:[~2020-05-06 0:59 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 13:19 sidneym
2020-04-15 16:30 ` Rich Felker
2020-04-15 17:50 ` sidneym
2020-04-15 18:06 ` Szabolcs Nagy
2020-04-15 18:22 ` sidneym
2020-04-16 9:36 ` Szabolcs Nagy
2020-04-16 15:34 ` Rich Felker
2020-04-16 16:26 ` sidneym
2020-04-16 16:34 ` 'Rich Felker'
2020-04-15 18:26 ` Rich Felker
2020-04-15 19:12 ` sidneym
2020-04-15 19:29 ` 'Rich Felker'
2020-04-30 22:44 ` sidneym
2020-04-30 23:51 ` Rich Felker
2020-05-05 23:37 ` sidneym
2020-05-06 0:59 ` Rich Felker [this message]
2020-06-18 16:37 ` sidneym
2020-06-18 21:42 ` Szabolcs Nagy
2020-06-19 21:58 ` sidneym
2020-06-19 22:46 ` Rich Felker
2020-06-20 0:03 ` [musl] strtok Robert Skopalík
2020-06-20 0:15 ` Rich Felker
2020-06-20 0:36 ` Robert Skopalík
2020-06-20 0:46 ` Robert Skopalík
2020-06-20 1:44 ` Rich Felker
2020-06-20 7:07 ` Patrick Oppenlander
2020-06-20 13:00 ` Robert Skopalík
2020-06-22 0:57 ` Bery Saidi
2020-06-20 2:29 ` [musl] Hexagon DSP support sidneym
2020-06-20 3:20 ` Rich Felker
2020-07-20 21:26 ` sidneym
2020-07-23 21:56 ` Szabolcs Nagy
2020-07-24 17:49 ` sidneym
2020-09-16 20:49 ` sidneym
2020-09-17 1:32 ` 'Rich Felker'
2020-09-17 22:31 ` sidneym
2020-09-18 1:08 ` Rich Felker
2020-09-18 8:10 ` Szabolcs Nagy
2020-09-20 13:12 ` sidneym
2020-09-20 17:17 ` 'Rich Felker'
2020-09-21 14:09 ` sidneym
2020-04-15 18:55 ` Fangrui Song
2021-03-09 20:25 sidneym
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200506005929.GG21576@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=sidneym@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).