This is the mail archive of the
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 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.
>  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:
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?
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
>> Then gdbserver will tell in QSupported that it e.g. support
>> 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
> 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.
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible