Re: [RFC] reviving 'catch syscall' for gdbserver

[Sergio Durigan Junior <sergiodj at redhat dot com>]

On Friday, September 11 2015, Josh Stone wrote:

> 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

Hi Josh,

First of all, thanks for the patch and for reviving.  This e-mail is not
really an in-depth reply; just a few things I would like to mention from
the top of my head.

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

I pushed:

  <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=458c8db89f7e9913da6fa67c3df73404375c436b>

  (discussion: <https://sourceware.org/ml/gdb-patches/2014-11/msg00227.html>)

meanwhile, which should help address this issue (though it doesn't fix
the whole problem).  You might be interested in reading
https://sourceware.org/bugzilla/show_bug.cgi?id=10737 as well.

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

That's my understanding as well.  I'd say go ahead with QCatchSyscalls.

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

I'll see if I can have some time this weekend to resume my work on this.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/