[Top][All Lists]

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

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

From: Laurent Vivier
Subject: Re: [PATCH v2 00/20] linux-user: generate syscall_nr.sh
Date: Fri, 21 Feb 2020 15:29:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Le 21/02/2020 à 14:45, Peter Maydell a écrit :
> On Wed, 19 Feb 2020 at 22:07, 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.
> 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:


 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.


reply via email to

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