This is the mail archive of the
mailing list for the GDB project.
Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver)
- From: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 09 Oct 2013 23:54:43 +0200
- Subject: Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was 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> <m3bo3ec7cp dot fsf at redhat dot com> <1380467062 dot 3567 dot 52 dot camel at soleil> <524DBA28 dot 3070706 at redhat dot com> <1380837750 dot 2217 dot 104 dot camel at soleil> <524EFB00 dot 90105 at redhat dot com> <524FD8A9 dot 2010006 at redhat dot com>
On Sat, 2013-10-05 at 10:15 +0100, Pedro Alves wrote:
> I don't have time right now for a more elaborate answer, but ...
> On 10/04/2013 06:29 PM, Pedro Alves wrote:
> > Thinking only in terms of multi-process/thread, I'm inclined to ignore the
> > "per-process" thing now, and just leave it as gdbserver making catch
> > syscall apply to all processes.
> I just realized that we really can't do that. The syscall numbers
> sent across the wire are the target-specific numbers. Since gdbserver
> might well be debugging processes of different gdbarch's simultaneously
> (see the multi-arch support patches from a while ago, the tdesc support
> in gdbserver, etc.), we can't assume the same syscall array makes sense
> for all processes under gdbserver's control.
Getting back to this after a period of other activitites,
here is a suggested list of approaches
to address the major comments given in various mails:
* QCatchSyscalls contains target specific numbers (this is the
=> have gdbserver handling QCatchSyscalls packet per inferior
* ensure QCatchSyscall packet can (in the future) be extended with
a COND_LIST (similar to the Z packets).
To do that, I suggest to have the QCatchSyscalls separating syscall
numbers with a , rather than a ;
(so that a ; can be used later to separate the list of syscalls
from the COND_LIST)
Note: Luis suggested the alternative to have a packet
Then gdbserver will tell in QSupported that it e.g. support
For what concerns the problem of identifying which catchpoint
to remove in the QRemoveCatchPoint: not too sure we need
an catch point id for that. We can assume that an QInsertCatchPoint
of a certain kind fully replace the previously inserted catchpoint
of the same kind. A QRemoveCatchpoint removes completely
the catchpoint of the same kind.
I can go the QInsertCatchPoint way if it is confirmed this is a better
* Need to investigate the bug in gdb 'catch syscall' flip/flop logic.
If this logic can be fixed, then have gdbserver and gdb using
the same logic.
* extend the stop reply packet to allow to return a
"syscall" stop reason that does not specify if this is a syscall
entry or exit.
I suggest to do this even if a correct flip/flop logic can be
found during the previous investigation.
This 3rd syscall stop reason allow stubs to report a syscall
without necessarily having the logic to differentiate entry
Any comments about the above approaches ?
(in particular, about the choice between QCatchSyscalls