Hi all,

I've been using Philippe's QCatchSyscalls patch[1] for gdbserver, and
I'd like to reopen the discussion about merging this patch.  Philippe
told me would be fine with me taking this up, as he doesn't have time to
work on it now.

[1] https://sourceware.org/ml/gdb-patches/2013-09/msg00992.html

I've rebased the patch onto current gdb.git master, attached.  Some
things are simplified by various refactoring done in the last two years,
but otherwise I didn't change any capability from what he had.

I haven't included formalities like ChangeLogs here, because I would
like to get basic consensus on the approach first.  I also don't know
the right way to approach authorship here, between what Philippe
originally wrote and my changes since, for what's ultimately committed.

I tested catch-syscall.exp on Fedora 22 x86_64, for targets unix,
native-gdbserver, and native-extended-gdbserver, and all passed.

Philippe pointed me to his last summary of issues, which I'd like to
start the discussion with:
https://sourceware.org/ml/gdb-patches/2013-10/msg00321.html

> * QCatchSyscalls contains target specific numbers (this is the
>   above comment)
>   => have gdbserver handling QCatchSyscalls packet per inferior

Does this still need to be per-inferior?  I do understand that syscall
numbers may differ, e.g. from i686 to x86_64 on the same target.  Are
there any other examples of such things that are dealt with separately?

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

I notice that fork and vfork events have since been implemented on their
own as simple qSupported flags.  So I guess this idea of a generic
QInsertCatchPoint idea was dropped?

Maybe syscalls should similarly use a qSupported syscall-events flag for
basic enabling.  Then QCatchSyscalls would only be used to select
specific syscalls, sort of how QPassSignals is used.

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

I guess this is referring gdb's simple toggling, vs gdbserver's ENOSYS
method of detecting syscall entry vs return.  Can someone point to the
bug in gdb's flip/flop?  (strace is also a toggler, btw)

FWIW, I think it is possible for Linux to know this precisely.  AFAIK
the only way to catch a syscall return is with PTRACE_SYSCALL from a
syscall entry *or* from one of the mid-syscall events, like a
PTRACE_EVENT_FORK.  Any other time, a syscall stop can only be entry.

I can see how flip/flop might get confused if 'catch syscall' was only
enabled when the target was already stopped on that fork, for instance.
 But if you mark that fork like being in an entry, then it will toggle
to return correctly afterward.  Enabling 'catch syscall' at any other
time should start at IGNORE, so the next is then entry.

But I expect I'm missing things.  I'd like to hear what other demons are
lurking around this...

(I also know Sergio was tinkering with a ptrace patch to distinguish
entry/return precisely in the kernel, which would be nice for all.)

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

I'm not keen on this, personally.  If a stub can't keep proper track of
this, it seems unlikely that the remote gdb can do it better.

I'm sure I'm probably missing some points from only having skimmed the
rest of the prior threads.  Please do let me know.

I look forward to any feedback!

Thanks,
Josh