This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver
- From: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: "Agovic, Sanimir" <sanimir dot agovic at intel dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 26 Sep 2013 00:54:46 +0200
- Subject: Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1379796907 dot 5980 dot 20 dot camel at soleil> <0377C58828D86C4588AEEC42FC3B85A717680EC1 at IRSMSX105 dot ger dot corp dot intel dot com> <1379964754 dot 2226 dot 6 dot camel at soleil> <0377C58828D86C4588AEEC42FC3B85A7176814E1 at IRSMSX105 dot ger dot corp dot intel dot com> <m3ob7ghmcx dot fsf at redhat dot com>
On Wed, 2013-09-25 at 13:55 -0300, Sergio Durigan Junior wrote:
> On Tuesday, September 24 2013, Sanimir Agovic wrote:
>
> >> > Is it sufficient to assign sysno/sysret to 0 to indicate missing 'catch syscall'
> >> > functionality? Both values seem legal to me.
> >> The idea is that will be used in case the user forces the use of the
> >> QCatchSyscalls packet. So, I think it is better to return "valid" (but
> >> not used) values : I do not think there is a syscall nr 0.
> >>
> > gdb -batch -ex 'set architecture i386:x86-64' -ex 'catch syscall 0'
> > The target architecture is assumed to be i386:x86-64
> > Catchpoint 1 (syscall 'read' [0])
> >
> > I just wanted to make sure that we do not report any false syscalls.
> > Thus I checked syscall 0 in gdb on amd64 which is mapped to 'read'.
>
> Thanks for catching that. I guess I had to solve the same problem for
> the native "catch syscall". If you look at the UNKNOWN_SYSCALL define
> (it's on gdbarch.h), you'll see that I have chosen the value of -1. I
> guess you could use the same trick, Philippe. WDYT?
I tested with the 0 value, and effectively that gives a "read" syscall
on x86-64, which is not ideal, even if that would happen only when
the user does something strange (forcing to activate a packet with
a gdbserver which has not reported it can handle such packet).
-1 looks a good "bad" value, assuming that the gdb+protocol+gdbserver
will be able to "correctly" handle negative numbers.
I will test this behaviour (probably this WE).
Also, ping ... :
if before this WE, a maintainer reviews the patch, I will be more
than happy to handle the comments :)
Philippe