[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/22] linux-user: generate syscall_nr.sh

From: Laurent Vivier
Subject: Re: [PATCH 00/22] linux-user: generate syscall_nr.sh
Date: Tue, 18 Feb 2020 16:19:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Le 18/02/2020 à 15:27, Cornelia Huck a écrit :
> On Mon, 17 Feb 2020 23:35:36 +0100
> Laurent Vivier <address@hidden> wrote:
>> This series copies the files syscall.tbl from linux v5.5 and generates
>> the file syscall_nr.h from them.
>> This is done for all the QEMU targets that have a syscall.tbl
>> in the linux source tree: mips, mips64, i386, x86_64, sparc, s390x,
>> ppc, arm, microblaze, sh4, xtensa, m68k, hppa and alpha.
>> tilegx and cris are depecrated in linux (tilegx has no maintainer in QEMU)
>> aarch64, nios2, openrisc and riscv have no syscall.tbl in linux.
>> It seems there is a bug in QEMU that forces to disable manually arch_prctl
>> with i386 target: do_arch_prctl() is only defined with TARGET_ABI32 but
>> TARGET_ABI32 is never defined with TARGET_I386 (nor TARGET_X86_64).
>> I have also removed all syscalls in s390x/syscall_nr.h defined for
>> !defined(TARGET_S390X).
>> I have added a script to copy all these files from linux and updated
>> them at the end of the series with their latest version for today.
>> The two last patches manage the special case for mips O32 that needs
>> to know the number of arguments. We find them in strace sources.
> I like the idea of generating those files, but I wonder if that should
> interact with linux-headers updates.
> I plan to do a linux-headers update to 5.6-rc?, and I noticed that this
> will drag in two new syscalls (openat2 and pidfd_getfd). Now, just
> having the new #defines in the headers doesn't do anything, but should
> it be a trigger to update the syscall.tbl files as well? Or does that
> need manual inspection/updating?

I think it's a good idea to update the syscall.tbl when we update
linux-headers, and there will be no change at linux-user level while we
don't implement the syscall translation in syscall.c:do_syscall1().

But I think we should also check manually the difference between new and
old generated syscall_nr.h to be sure there is nothing broken in what we

I always run a Linux Test Project testsuite for all architectures with a
debian distro when I do a pull request so I can detect regression.

In the end, updating linux-headers should trigger syscall.tbl update but
it needs manual inspection.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]