Re: [PATCH] Linux: Add tables with system call numbers

[Florian Weimer <fweimer at redhat dot com>]

* Zack Weinberg:

> On Tue, May 28, 2019 at 6:10 PM Florian Weimer <fweimer@redhat.com> wrote:
> ...
>> The goal is to use these architecture-specific tables to ensure
>> that system call wrappers are available irrespective of the version
>> of the installed kernel headers.
>>
>> The tables are formatted in the form of C header files so that they
>> can be used directly in an #include directive, without external
>> preprocessing.  (External preprocessing of a plain table file
>> would introduce cross-subdirectory dependency issues.)  However,
>> the intent is that they can still be treated as tables and processed
>> by simple tools.
>
> Is there any reason why, instead of inventing a new name
> "arch-syscall.h", these tables could not be checked in as
> bits/syscall.h for each architecture, allowing us to eliminate the
> process of generating bits/syscall.h at build time, and decoupling our
> sys/syscall.h altogether from the installed kernel headers?

I think I explained in a comment somewhere that it is desirable to still
have the global list, so that the SYS_ names magically show up if a
known system call is wired up for any architecture, without upgrade or
rebuilding glibc.

This is the result of our experience that system call numbers are
assinged at different times (upstream, but also in downstream
backports).

I think it is still desirable to have the global list, so that building
one architecture does not need to walk the source tree to find all
arch-syscall.h files.  But I can probably implement that if you prefer
this mechanism.

> They would need a little boilerplate at top and bottom, which
> shouldn't be a big deal, and they would have to define the SYS_ names
> rather than the __NR_ names, but my old-fashioned heart is inclined to
> say that that's a win anyway, the __NR_ names were never part of *our*
> official API, include <asm/unistd.h> yourself if you want them.

The __NR_ names are widely used in the source tree.  We can replace
them, but the second patch would be much, much larger.

I initially wanted to move in that direction, but I'm not sure if such a
massive patch would be acceptable.  If we want to go there, I'd rather
prefer not using SYS_ or __NR_ prefixes in this case, but some separate,
glibc-specific.

> Relatedly, I think gen-syscall-h.awk could be recycled as the
> script Joseph wants (perhaps rewritten in Python).

I think this does something else.

> A couple of small notes on the patch (this is not a full review):
>
>> +++ b/sysdeps/unix/sysv/linux/glibcsyscalls.py
>> @@ -0,0 +1,141 @@
>> +#!/usr/bin/python3
>> +# Helpers for glibc system call list processing.
>> +# Copyright (C) 2018-2019 Free Software Foundation, Inc.
>> +# This file is part of the GNU C Library.
>
> This appears _not_ to be the script Joseph was asking for.  Could you
> please make it clearer in the file what it does do?

It's a set of helper functions, and in contrast to
scripts/glibcextract.py, it is Linux-specific.  Not sure how to describe
it better.

>> diff --git a/sysdeps/unix/sysv/linux/syscall-names.list b/sysdeps/unix/sysv/linux/syscall-names.list
>> index 2d0354b8b3..9a51b46cbb 100644
>> --- a/sysdeps/unix/sysv/linux/syscall-names.list
>> +++ b/sysdeps/unix/sysv/linux/syscall-names.list
>> @@ -499,6 +499,7 @@ set_mempolicy
>>  set_robust_list
>>  set_thread_area
>>  set_tid_address
>> +set_tls
>>  setdomainname
>>  setfsgid
>>  setfsgid32
>
> This should probably happen as a separate patch.

I can do that.  It's only needed because we don't recognize the set_tls
system call for Arm as it is listed in the kernel headers.  (cacheflush
is already used by another architecture.)  A few Arm system calls have
irregular names not starting with __NR_.

>> diff --git a/sysdeps/unix/sysv/linux/x86_64/x32/arch-syscall.h b/sysdeps/unix/sysv/linux/x86_64/x32/arch-syscall.h
>> new file mode 100644
>> index 0000000000..ef4ec281ef
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/x86_64/x32/arch-syscall.h
>> @@ -0,0 +1,324 @@
>> +#define __NR_accept 1073741867
>
> Would it be possible to make this come out as (0x40000000 | 43), and
> similarly for the others?

Can you clarify why you would want to do this?  Some projects probably
would like us to ship the numbers as a JSON file, so that they can be
consumed *without* a preprocessor.

Thanks,
Florian