Message ID | 20200219220333.1411905-1-laurent@vivier.eu |
---|---|
Headers | show |
Series | linux-user: generate syscall_nr.sh | expand |
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 ? 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
On Fri, 21 Feb 2020 at 13:45, Peter Maydell <peter.maydell@linaro.org> wrote: > > 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 ? I think that for asm-generic we should be able to generate the syscall_nr.h by suitably defining a __SYSCALL macro before #including linux-headers/asm-whatever/unistd.h -- They basically define syscall numbers like this: #define __NR_setxattr 5 __SYSCALL(__NR_setxattr, sys_setxattr) so a C program that just did the autogeneration has the info it needs. thanks -- PMM
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
Le 21/02/2020 à 14:56, Peter Maydell a écrit : > On Fri, 21 Feb 2020 at 13:45, Peter Maydell <peter.maydell@linaro.org> wrote: >> >> 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 ? > > I think that for asm-generic we should be able to generate > the syscall_nr.h by suitably defining a __SYSCALL macro > before #including linux-headers/asm-whatever/unistd.h -- > They basically define syscall numbers like this: > #define __NR_setxattr 5 > __SYSCALL(__NR_setxattr, sys_setxattr) > > so a C program that just did the autogeneration has the > info it needs. Thank you for the hint. I will have a look. Thanks, Laurent