On Wed, 19 Feb 2020 at 22:07, Laurent Vivier <laur...@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 ? 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
