This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] reviving 'catch syscall' for gdbserver
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Josh Stone <jistone at redhat dot com>
- Cc: gdb-patches at sourceware dot org, philippe dot waroquiers at skynet dot be, palves at redhat dot com
- Date: Fri, 11 Sep 2015 22:27:41 -0400
- Subject: Re: [RFC] reviving 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <55F3838A dot 4010005 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/