Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver)

Philippe Waroquiers
2013-10-09T21:54:21Z

On Sat, 2013-10-05 at 10:15 +0100, Pedro Alves wrote:
> Hi,
>
> 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.
>

Hello,

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
above comment)
=> 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
QInsertCatchPoint:[fork|syscall|exec|...]
Then gdbserver will tell in QSupported that it e.g. support
QInsertCatchPoint=syscall,fork

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
approach.

* 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
from return.

Any comments about the above approaches ?
(in particular, about the choice between QCatchSyscalls
and QInsertCatchPoint).

Thanks

Philippe