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

[Peter Maydell]

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 ?

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.

> 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?

thanks
-- PMM