public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Set unknown_syscall differently on arm linux
@ 2016-06-28  9:26 Yao Qi
  2016-06-29  9:53 ` Pedro Alves
  2016-06-29 17:41 ` Mike Frysinger
  0 siblings, 2 replies; 8+ messages in thread
From: Yao Qi @ 2016-06-28  9:26 UTC (permalink / raw)
  To: gdb-patches

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(+)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.c b/gdb/testsuite/gdb.base/catch-syscall.c
index 98222fa..2e3c5d1 100644
--- 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;
 
 /* Set by the test when it wants execve.  */
-- 
1.9.1

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-28  9:26 [PATCH] Set unknown_syscall differently on arm linux Yao Qi
@ 2016-06-29  9:53 ` Pedro Alves
  2016-06-29 13:56   ` Yao Qi
  2016-06-29 17:41 ` Mike Frysinger
  1 sibling, 1 reply; 8+ messages in thread
From: Pedro Alves @ 2016-06-29  9:53 UTC (permalink / raw)
  To: Yao Qi, gdb-patches

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-29  9:53 ` Pedro Alves
@ 2016-06-29 13:56   ` Yao Qi
  0 siblings, 0 replies; 8+ messages in thread
From: Yao Qi @ 2016-06-29 13:56 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

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.

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-28  9:26 [PATCH] Set unknown_syscall differently on arm linux Yao Qi
  2016-06-29  9:53 ` Pedro Alves
@ 2016-06-29 17:41 ` Mike Frysinger
  2016-06-30  7:52   ` Yao Qi
  1 sibling, 1 reply; 8+ messages in thread
From: Mike Frysinger @ 2016-06-29 17:41 UTC (permalink / raw)
  To: Yao Qi; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-29 17:41 ` Mike Frysinger
@ 2016-06-30  7:52   ` Yao Qi
  2016-06-30 12:58     ` Mike Frysinger
  0 siblings, 1 reply; 8+ messages in thread
From: Yao Qi @ 2016-06-30  7:52 UTC (permalink / raw)
  To: Yao Qi, gdb-patches

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.

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-30  7:52   ` Yao Qi
@ 2016-06-30 12:58     ` Mike Frysinger
  2016-06-30 14:48       ` Yao Qi
  0 siblings, 1 reply; 8+ messages in thread
From: Mike Frysinger @ 2016-06-30 12:58 UTC (permalink / raw)
  To: Yao Qi; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-30 12:58     ` Mike Frysinger
@ 2016-06-30 14:48       ` Yao Qi
  2016-07-04  2:20         ` Mike Frysinger
  0 siblings, 1 reply; 8+ messages in thread
From: Yao Qi @ 2016-06-30 14:48 UTC (permalink / raw)
  To: Yao Qi, gdb-patches

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?

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Set unknown_syscall differently on arm linux
  2016-06-30 14:48       ` Yao Qi
@ 2016-07-04  2:20         ` Mike Frysinger
  0 siblings, 0 replies; 8+ messages in thread
From: Mike Frysinger @ 2016-07-04  2:20 UTC (permalink / raw)
  To: Yao Qi; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-07-04  2:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-28  9:26 [PATCH] Set unknown_syscall differently on arm linux Yao Qi
2016-06-29  9:53 ` Pedro Alves
2016-06-29 13:56   ` Yao Qi
2016-06-29 17:41 ` Mike Frysinger
2016-06-30  7:52   ` Yao Qi
2016-06-30 12:58     ` Mike Frysinger
2016-06-30 14:48       ` Yao Qi
2016-07-04  2:20         ` Mike Frysinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).