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

From: Laurent Vivier <laurent@vivier.eu>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Cornelia Huck <cohuck@redhat.com>,
	Riku Voipio <riku.voipio@iki.fi>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	Aleksandar Markovic <amarkovic@wavecomp.com>,
	Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [PATCH v2 00/20] linux-user: generate syscall_nr.sh
Date: Fri, 21 Feb 2020 15:29:45 +0100	[thread overview]
Message-ID: <6050c10c-5911-ac76-f79e-5966e5e1faf6@vivier.eu> (raw)
In-Reply-To: <CAFEAcA8g+uRrGuNLdURegmpjRLtk=vVC9zUE1+QVKRitPjJy7A@mail.gmail.com>

Le 21/02/2020 à 14:45, Peter Maydell a écrit :
> On Wed, 19 Feb 2020 at 22:07, Laurent Vivier <laurent@vivier.eu> 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.
> 
> Is it the case that all our architectures either:
>  (1) have a syscall.tbl
>  (2) are using the asm-generic common numbering system ?

Yes, for what I see archs that have not been converted to syscall.tbl
are the ones using asm-generic common numbering system.

> 
> Though even if they do use asm-generic there's awkwardness
> still around whether they have extra arch-specific syscalls
> and what features of the asm-generic/unistd.h they select,
> so I'm not sure whether it helps us much to know that they're
> sharing a basically common numbering system.
> 
> It does suggest that future architectures are unlikely to have
> a syscall.tbl unless somebody pushes for one to be generated
> for asm-generic users.

I agree.

> 
>> 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).
> 
> TARGET_ABI32 for x86 would mean the x32 "32-bit APIs
> on a 64-bit CPU", which we don't implement. But the
> guards on do_arch_prctl() are
> #if defined(TARGET_I386) && !defined(TARGET_ABI32)
> 
> where the !TARGET_ABI32 check seems like it's unnecessary but
> harmless (we never define it for x86), so what causes a problem?

Yes, my conclusion was too quick.

The error is:

  CC      i386-linux-user/linux-user/syscall.o
linux-user/syscall.c: In function 'do_syscall1':
linux-user/syscall.c:10208:2: error: #error unreachable
10208 | #error unreachable
      |  ^~~~~

So something defines TARGET_ABI32:

include/exec/user/abitypes.h

 42 #ifdef TARGET_ABI32
...
 54 #else
...
 60 /* for consistency, define ABI32 too */
 61 #if TARGET_ABI_BITS == 32
 62 #define TARGET_ABI32 1
 63 #endif
...
 70 #endif

TARGET_ABI32 is always defined if TARGET_ABI_BITS is 32 (and i386 is 32bit)

An the problem is more complex.

do_arch_prctl() uses TARGET_ARCH_SET_GS, TARGET_ARCH_SET_FS,
TARGET_ARCH_GET_GS and TARGET_ARCH_GET_FS that are defined in
linux-user/x86_64/target_syscall.h and not in i386.

Thanks,
Laurent