[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall
From: |
Laurent Vivier |
Subject: |
Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64 |
Date: |
Sat, 2 Jul 2016 23:17:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
Le 02/07/2016 à 22:12, Peter Maydell a écrit :
> On 2 July 2016 at 17:41, Laurent Vivier <address@hidden> wrote:
>> Sadly, this can't work:
>>
>> sparc/sparc64/cris use sys_select for NR_select AND NR_newselect.
>
>> Not sure all is correct, but it's what I've found:
>>
>> | __NR_select | __NR__newselect
>> ------------+----------------+-----------------+
>> arm | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> aarch64 | sys_select | - |
>> ------------+----------------+-----------------+
>> alpha | sys_select | - |
>> ------------+----------------+-----------------+
>> cris | sys_select | sys_select |
>> ------------+----------------+-----------------+
>> m68k | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> microblaze | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> mips | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> mips64 | sys_select | - |
>> ------------+----------------+-----------------+
>> openrisc | sys_select | - |
>> ------------+----------------+-----------------+
>> ppc | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> s390x | sys_select | - |
>> ------------+----------------+-----------------+
>> sh4 | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>> sparc | sys_select | sys_select |
>> ------------+----------------+-----------------+
>> sparc64 | sys_select | sys_select |
>> ------------+----------------+-----------------+
>> tilegx | sys_select | - |
>> ------------+----------------+-----------------+
>> unicore32 | sys_select | - |
>> ------------+----------------+-----------------+
>> x86_64 | sys_select | - |
>> ------------+----------------+-----------------+
>> i386 | sys_old_select | sys_select |
>> ------------+----------------+-----------------+
>
> Hmm. Looking at current Linux git master, I get
> slightly different results. The only architectures which
> define __ARCH_WANT_SYS_OLD_SELECT are:
Where is defined this __ARCH_WANT_SYS_OLD_SELECT?
> arm, m68k, mn10300, x86
> and no others use sys_old_select.
You're right, NR_select is sys_ni_syscall for:
microblaze, mips32, sh4, ppc64
arch/microblaze/kernel/syscall_table.S: .long sys_ni_syscall /*
old_select */
arch/mips/kernel/scall32-o32.S: PTR sys_ni_syscall /*
old_select */
arch/sh/kernel/syscalls_32.S: .long sys_ni_syscall /* sys_oldselect */
arch/pwoerpc/include/asm/systbl.h:SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
but I have supposed that it was set to sys_old_select for older kernel.
[but in 1.3.48, it is already sys_ni_syscall for mips... so we must
really manage that as ENOSYS)
In x86, old_select is used for the 32bit version, not for the 64bit:
entry/syscalls/syscall_32.tbl
82 i386 select sys_old_select
compat_sys_old_select
> So I think we have the following behaviours:
>
> (1) Define neither NR_select nor NR__newselect
> (and use pselect6 syscall for select):
> aarch64, openrisc, tilegx, unicore32, presumably any future arch
They use:
kernel/sys.c:
#undef __SYSCALL
#define __SYSCALL(nr, call) [nr] = (call),
void *sys_call_table[__NR_syscalls] = {
#include <asm/unistd.h>
};
It's not very clear, but I think they use NR_select with sys_select:
include/uapi/asm-generic/unistd.h
#define __ARCH_WANT_SYS_SELECT
__SYSCALL(__NR_select, sys_select)
> (2) only define NR__newselect, it is new select:
> mips, mips64, sh, s390
>
> (3) Only define NR_select, want that to be new select:
> alpha, x86_64, s390x
>
> (4) NR__newselect is new select, NR_select is old_select:
> i386, m68k, arm if kernel is not CONFIG_AEABI
>
> (5) NR__newselect is new select, NR_select is defined but
> if called returns ENOSYS:
> microblaze, arm if CONFIG_AEABI, ppc64
>
> (6) NR__newselect is new select, NR_select is a bonkers custom
> thing that tries to autodetect the calling convention:
> http://lxr.free-electrons.com/source/arch/powerpc/kernel/syscalls.c#L86
> ppc32 (but only native 32-bit; 32-bit compat support
> on a ppc64 kernel is category 5, so I vote for ignoring
> this weirdness and calling ppc category 5)
>
> (7) NR_select and NR__newselect are different numbers
> but both are new select:
> cris, sparc, sparc64
>
> which is a pretty confusing mess, but I think it equates to:
> (0) if defined, NR__newselect is always new select
> (1) if NR_select is defined, the choices are:
> (a) NR_select is old_select:
> i386, m68k, arm
> (b) NR_select is defined but should ENOSYS:
> microblaze, ppc
> (c) NR_select defined and is new select:
> everything else (alpha, x86-64, s390x, cris, sparc, sparc64)
>
> and I think we should handle that by having the code in syscall.c
> be something like:
>
> #ifdef TARGET_NR_select
> case TARGET_NR_select:
> #if defined(TARGET_WANT_NI_OLD_SELECT)
> /* some architectures used to have old_select here
> * but now ENOSYS it.
> */
> ret = -TARGET_ENOSYS;
> break;
> #elif defined(TARGET_WANT_OLD_SYS_SELECT)
> /* code for old select here; maybe factored out to
> * its own function: ret = do_old_select() ?
> */
> #else
> /* select is new style select */
> ret = do_select(...);
> #endif
> #endif
>
> where TARGET_WANT_NI_OLD_SELECT and
> TARGET_WANT_OLD_SYS_SELECT are #defined in
> linux-user/$(ARCH)/target_syscall.h by those
> architectures that need that behaviour
> (microblaze, ppc for the first; i386, m68k, arm
> for the second).
> We could just not define TARGET_NR_select for
> microblaze and ppc, of course, but that might
> be confusing and easily accidentally reverted.
>
> For openrisc, sh and tilegx we incorrectly define
> a TARGET_NR_select which the kernel doesn't, so
> we should delete that from our headers.
I think they really exist (from asm-generic/unistd.h)
> I think overall that produces a reasonable separation
> of "what behaviour does my architecture want" from
> the implementation of the various behaviours, and
> means the default will be correct for any architectures
> we add later (only the oddball legacy cases need
> to request special behaviour).
I agree.
Thanks,
Laurent
- [Qemu-trivial] [PATCH] linux-user: fix signal() syscall on x86_64, Wirth, Allan, 2016/07/01
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Peter Maydell, 2016/07/01
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Wirth, Allan, 2016/07/01
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Laurent Vivier, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Peter Maydell, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Laurent Vivier, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Peter Maydell, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64,
Laurent Vivier <=
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Peter Maydell, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Laurent Vivier, 2016/07/02
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Riku Voipio, 2016/07/07
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Laurent Vivier, 2016/07/07
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Wirth, Allan, 2016/07/07
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Laurent Vivier, 2016/07/07
- Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: fix signal() syscall on x86_64, Wirth, Allan, 2016/07/07