This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: Add tables with system call numbers
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Jun 2019 14:29:38 +0200
- Subject: Re: [PATCH] Linux: Add tables with system call numbers
- References: <87o93mqlhj.fsf@oldenburg2.str.redhat.com> <CAKCAbMgdtKtrBT_bX96Q6NGF+Hmwj1qrSkb_nr=XWE6HXOgoKw@mail.gmail.com> <87blzlret5.fsf@oldenburg2.str.redhat.com> <CAKCAbMj3J4Aw7qv-+RAuEwDVxE_WmeAPZUmbtZmrit_tKQzgZA@mail.gmail.com>
* Zack Weinberg:
> On Wed, May 29, 2019 at 1:48 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * 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.
>
> I don't understand why a global list of known system calls is
> incompatible with the checked-in architecture-specific lists of system
> call numbers (in the form of a C header file) being the bits/syscall.h
> for each architecture. I'm just trying to avoid having two header
> files with very nearly the same function.
bits/syscall.h intentionally covers a superset of all names currently
available for the architecture. We used to auto-generate it from
<asm/unistd.h> at build time in glibc, but that caused unwanted
dependencies on kernel headers and system-call backporting efforts (the
backport had to land on all architectures before you could build the
final glibc for a release). The global names-only list avoids that.
>> >> +++ 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.
>
> Helper functions for what, though? I couldn't find uses in the patch,
> possibly because the arch-syscall.h files are so long and repetitive
> that I missed them. (It might be helpful to post all of the code that
> needs reviewing as a separate patch from the creation of the
> arch-syscall.h files.)
Helpers for parsing system call lists in various formats: the global
names list, <asm/unistd.h>, our in-tree lists.
>
>> >> 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?
>
> Just to make clear to human readers that it's the same as __NR_accept
> for x86_64/64, plus a flag bit. (asm/unistd_x32.h does this.)
I'm not sure if it makes sense to add this complication. I read
somewhere that new architectures with ILP32 are not supposed to repeat
this approach.
> Is the issue that you anticipate uses of these files by programs other
> than glibc's build process, and for which parsing a C integer constant
> expression would be inconvenient? Could you give examples, even if
> they have to be hypothetical?
Thinks like ljsyscall or anything else that wants to provide system call
access in a cross-language fashion.
Thnaks,
Florian