All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/aarch64: Remove 32 bit only syscalls
Date: Fri, 3 Sep 2021 11:03:33 +0000	[thread overview]
Message-ID: <CAK8P3a3wOfFnN5UQ6MC0z+PtCSmMz_3NFmatAuD1Lb6jH7J+YA@mail.gmail.com> (raw)
In-Reply-To: <YTG/MERCvZkBalov@pevik>

On Fri, Sep 3, 2021 at 6:22 AM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi all,
>
> > Hi Arnd,
>
> > On 9/2/2021 8:32 PM, Arnd Bergmann wrote:
>
> > > > > I am not 100% sure, how the syscall table for aarch64 is generated.
> > > > > There are also compat version for some of the 32 bit only 64 bit syscalls,
> > > > > but I think they are only available, when running an 32 bit arm application.
> > > The syscall table for aarch64 is generated from the kernel's
> > > include/uapi/asm-generic/unistd.h, which has a number of #ifdefs in
> > > it. A lot of these are disabled on aarch64 since they refer to older or
> > > 32-bit-only calls.
>
> > > https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html has a table
> > > with the correct set of syscalls for each architecture, and scripts to generate
> > > them from both the old asm-generic/unistd.h method (now only still used on
> > > modern architectures) and the newer syscall.tbl format (used on older
> > > architectures)
> @Arnd: thanks a lot for this table and explanations! I would not expect this
> kind of error in kernel sources.

I don't see anything wrong in the kernel sources here, just a little misleading
when read by a human rather than a compiler.

> When I changed / reviewed syscall numbers for LTP, I usually compared with
> kernel and musl sources. I never noticed change, but now I see for
> clock_gettime64 it's in musl only for arm (arch/arm/bits/syscall.h.in), but in
> kernel it's not only for arm, but also for arm64:
> arm64/include/asm/unistd.h:30:#define __NR_compat_clock_gettime64       403

This is a kernel-internal definition that is used to build the 32-bit VDSO. The
file is not made available to user space applications.

The file you need to look at for arm64 is include/uapi/asm-generic/unistd.h.
As I said, that file has a lot of #ifdefs and other magic in it, but I suppose
we could come up with a script to process it with /usr/bin/unifdef to only
get the parts you are interested in. Ideally though we would just
convert it into the modern machine-readable syscall.tbl format.

        Arnd

  reply	other threads:[~2021-09-03 11:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02  9:36 [LTP] [PATCH] syscalls/aarch64: Remove 32 bit only syscalls Joerg Vehlow
2021-09-02  9:42 ` Viresh Kumar
2021-09-02 18:32   ` Arnd Bergmann
2021-09-03  4:33     ` Joerg Vehlow
2021-09-03  6:22       ` Petr Vorel
2021-09-03 11:03         ` Arnd Bergmann [this message]
2021-09-03 12:20           ` Petr Vorel

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=CAK8P3a3wOfFnN5UQ6MC0z+PtCSmMz_3NFmatAuD1Lb6jH7J+YA@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=ltp@lists.linux.it \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.