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

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

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