[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/4] linux-user/arm: Handle invalid arm-specific syscalls cor
From: |
Peter Maydell |
Subject: |
Re: [PATCH 3/4] linux-user/arm: Handle invalid arm-specific syscalls correctly |
Date: |
Tue, 21 Apr 2020 10:34:11 +0100 |
On Tue, 21 Apr 2020 at 10:32, Aleksandar Markovic
<address@hidden> wrote:
>
> пон, 20. апр 2020. у 23:25 Peter Maydell <address@hidden> је
> написао/ла:
> >
> > The kernel has different handling for syscalls with invalid
> > numbers that are in the "arm-specific" range 0x9f0000 and up:
> > * 0x9f0000..0x9f07ff return -ENOSYS if not implemented
> > * other out of range syscalls cause a SIGILL
> > (see the kernel's arch/arm/kernel/traps.c:arm_syscall())
> >
> > Implement this distinction. (Note that our code doesn't look
> > quite like the kernel's, because we have removed the
> > 0x900000 prefix by this point, whereas the kernel retains
> > it in arm_syscall().)
> >
>
> Hmm, I suspect other targets could have a similar problem.
>
> I am definitely going to take a look at the mips target, but did
> you Peter have a chance to take a more global look whether
> this problem is actually widespread?
My guess is that this is Arm-specific, because both the OABI-vs-EABI
"do we pass the syscall number in the insn immediate field or
via a register" changeover and also the oddball "arm-specific
handful of syscalls in a distinct range" are Arm hacks, not
something the kernel deals with in generic code.
thanks
-- PMM
- Re: [PATCH 1/4] linux-user/arm: BKPT should cause SIGTRAP, not be a syscall, (continued)