mailing list of musl libc
 help / color / mirror / code / Atom feed
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

  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).