Set unknown_syscall differently on arm linux

  Currently, we use 123456789 as unknown or illegal syscall number, and
expect program return ENOSYS.  Although 123456789 is an illegal syscall
number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
However, arm linux kernel returns -ENOSYS if syscall number is within
0xf0001..0xf07ff, so we can use 0xf07ff for unknown_syscall in test.

gdb/testsuite:

2016-06-28  Yao Qi  <yao.qi@linaro.org>

	* gdb.base/catch-syscall.c [__arm__]: Set unknown_syscall to
	0x0f07ff.
---
 gdb/testsuite/gdb.base/catch-syscall.c | 4 ++++
 1 file changed, 4 insertions(+)
  

On 06/28/2016 10:26 AM, Yao Qi wrote:
> Currently, we use 123456789 as unknown or illegal syscall number, and
> expect program return ENOSYS.  Although 123456789 is an illegal syscall
> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
> However, arm linux kernel returns -ENOSYS if syscall number is within
> 0xf0001..0xf07ff, so we can use 0xf07ff for unknown_syscall in test.
> 

I think it'd be good if this was converted to a comment in the source.

> --- a/gdb/testsuite/gdb.base/catch-syscall.c
> +++ b/gdb/testsuite/gdb.base/catch-syscall.c
> @@ -28,7 +28,11 @@ int pipe_syscall = SYS_pipe;
>  int pipe2_syscall = SYS_pipe2;
>  #endif
>  int write_syscall = SYS_write;
> +#if defined(__arm__)
> +int unknown_syscall = 0x0f07ff;
> +#else
>  int unknown_syscall = 123456789;
> +#endif
>  int exit_group_syscall = SYS_exit_group;
>  

Thanks,
Pedro Alves
  

On Wed, Jun 29, 2016 at 10:53 AM, Pedro Alves <palves@redhat.com> wrote:
> On 06/28/2016 10:26 AM, Yao Qi wrote:
>> Currently, we use 123456789 as unknown or illegal syscall number, and
>> expect program return ENOSYS.  Although 123456789 is an illegal syscall
>> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
>> However, arm linux kernel returns -ENOSYS if syscall number is within
>> 0xf0001..0xf07ff, so we can use 0xf07ff for unknown_syscall in test.
>>
>
> I think it'd be good if this was converted to a comment in the source.
>

OK, I move them into the comments as below,

+#if defined(__arm__)
+/* Although 123456789 is an illegal syscall umber on arm linux, kernel
+   sends SIGILL rather than returns -ENOSYS.  However, arm linux kernel
+   returns -ENOSYS if syscall number is within 0xf0001..0xf07ff, so we
+   can use 0xf07ff for unknown_syscall in test.  */
+int unknown_syscall = 0x0f07ff;
+#else
 int unknown_syscall = 123456789;
+#endif

patch is pushed in.
  

On 28 Jun 2016 10:26, Yao Qi wrote:
> Currently, we use 123456789 as unknown or illegal syscall number, and
> expect program return ENOSYS.  Although 123456789 is an illegal syscall
> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.

err, what ?  calling random syscalls should not result in signals being
generated (ignoring obvious ones like __NR_kill).  is the kernel broken ?
i think this needs more investigation & explanation.
-mike
  

On Wed, Jun 29, 2016 at 6:41 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 28 Jun 2016 10:26, Yao Qi wrote:
>> Currently, we use 123456789 as unknown or illegal syscall number, and
>> expect program return ENOSYS.  Although 123456789 is an illegal syscall
>> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
>
> err, what ?  calling random syscalls should not result in signals being
> generated (ignoring obvious ones like __NR_kill).  is the kernel broken ?
> i think this needs more investigation & explanation.

I checked kernel source arch/arm/kernel/traps.c:arm_syscall, and that is how
I get the knowledge that kernel doesn't raise SIGIILL if sysno is within
0xf0001..0xf07ff.  That is intentional, but I don't know why arm kernel behaves
this way.
  

On 30 Jun 2016 08:52, Yao Qi wrote:
> On Wed, Jun 29, 2016 at 6:41 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 28 Jun 2016 10:26, Yao Qi wrote:
> >> Currently, we use 123456789 as unknown or illegal syscall number, and
> >> expect program return ENOSYS.  Although 123456789 is an illegal syscall
> >> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
> >
> > err, what ?  calling random syscalls should not result in signals being
> > generated (ignoring obvious ones like __NR_kill).  is the kernel broken ?
> > i think this needs more investigation & explanation.
> 
> I checked kernel source arch/arm/kernel/traps.c:arm_syscall, and that is how
> I get the knowledge that kernel doesn't raise SIGIILL if sysno is within
> 0xf0001..0xf07ff.  That is intentional, but I don't know why arm kernel behaves
> this way.

wow, that code is messed up.  can you raise a bug with them ?  there's
even more code paths in there that result in SIGSEGV too.  the history
predates 2.4.0 afaict.
-mike
  

On Thu, Jun 30, 2016 at 1:58 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
> wow, that code is messed up.  can you raise a bug with them ?  there's
> even more code paths in there that result in SIGSEGV too.  the history
> predates 2.4.0 afaict.

Sure, I can raise a bug somewhere or ask it in arm kernel mail list, but
why do you think it is a bug that SIGILL is raised when an illegal/unknown
syscall number is passed to syscall?  because other archs don't behave
this way?
  

On 30 Jun 2016 15:48, Yao Qi wrote:
> On Thu, Jun 30, 2016 at 1:58 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > wow, that code is messed up.  can you raise a bug with them ?  there's
> > even more code paths in there that result in SIGSEGV too.  the history
> > predates 2.4.0 afaict.
> 
> Sure, I can raise a bug somewhere or ask it in arm kernel mail list, but
> why do you think it is a bug that SIGILL is raised when an illegal/unknown
> syscall number is passed to syscall?  because other archs don't behave
> this way?

correct -- i know of no other arch that behaves this way.  the syscall
ABI is supposed to communicate errors via return values (which are errno
values), not by sending signals which kill the process.
-mike