This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC PATCH 0/3] Catch syscall group
- From: Doug Evans <dje at google dot com>
- To: Gabriel Krisman Bertazi <gabriel at krisman dot be>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 8 Oct 2014 12:12:41 -0400
- Subject: Re: [RFC PATCH 0/3] Catch syscall group
- Authentication-results: sourceware.org; auth=none
- References: <1412736678-2760-1-git-send-email-gabriel at krisman dot be>
On Tue, Oct 7, 2014 at 10:51 PM, Gabriel Krisman Bertazi
<gabriel@krisman.be> wrote:
> Hello,
>
> This multi-part patch implements on top of the 'catch syscall' command
> the ability to catch a group of related syscalls using a single
> command.
>
> The idea is to be able to catch a group of syscalls with a single
> command, just like we can do with the "-e trace" option in strace. We
> separate the syscalls in groups according to their functionality and
> allow users to say:
>
> (gdb) catch syscall network
>
> This creates a catchpoint for every network related syscall, such as
> bind, accept, connect...
>
> (Please note that adding this feature to GDB was first suggested by Tom
> Tromey on PR 15879. :-)
> <https://sourceware.org/bugzilla/show_bug.cgi?id=15879>).
>
> Right now, I've created syscall groups only for x86_64 and sorted the
> syscalls among them by using the same groups that strace has.
>
> I am sending this as an RFC because I still have a few questions before
> proposing this as a patch:
>
> 1) Whether a feature like this would be acceptable on GDB?
I think so.
> 2) About the command to catch syscall groups: I think it is more
> practical to just say "catch syscall network", instead of "catch syscall
> group network" or something like that. What would be the GDB way to do
> that? (I implemented the former, but I'd be happy to rewrite
> this part of the patch.)
I dunno. I think I prefer "catch syscall-group ...".
> 3) I think it is nice to have a command to list the syscall groups
> available. Maybe by saying "catch syscall group" with no arguments.
> What do you think?
It's too bad "catch syscall" catches any syscall, then "catch syscall"
could list them all. :-)
[To catch any syscall I'd have been ok with "catch syscall all".
Probably too late though - we certainly can't change the meaning of
"catch syscall".]
Playing around I found "complete catch syscall ." is a workaround.
Other non-alnum characters work too. I'm not suggesting this as a
proper solution. :-)
And it's probably a bug we should fix. :-)
I think we do need a solution to this though. At least in the case of
syscalls themselves, there's too many to include in the output of
"help catch syscall".
> 4) What kind of documentation should be updated when proposing the
> patch? Do I have to update only the GDB manual or should I provide
> patches for other documentation as well?
doc/gdb.texinfo and NEWS
> 5) Regarding the code design I propose here, do you have any concerns
> that I should fix right away before submiting this as a patch? Please
> share your thoughts :)
Have to spend a bit more time on this.
I thought we'd get some high level details ironed out first (in an
attempt to save you some typing).
> This patch series is divided as follows: Part 1 updates the xml-syscall
> interface to support the syscall group feature; Part 2 has the actual
> catchpoint code; Finally, Part 3 has the updated x86_64 xml, which
> defines the syscall groups for this architecture, and includes tests for
> this feature on x86_64.
>
> This presents no regressions on Fedora 20 x86 and x86_64.
>
> Thanks!
>
> Gabriel Krisman Bertazi (3):
> Implemement support for groups of syscalls in the xml-syscall
> interface.
> Add support to catch groups of syscalls.
> Create syscall groups for x86_64.
>
> gdb/breakpoint.c | 73 +++++--
> gdb/syscalls/amd64-linux.xml | 362 +++++++++++++++----------------
> gdb/syscalls/gdb-syscalls.dtd | 1 +
> gdb/testsuite/gdb.base/catch-syscall.exp | 25 +++
> gdb/xml-syscall.c | 183 +++++++++++++++-
> gdb/xml-syscall.h | 12 +
> 6 files changed, 453 insertions(+), 203 deletions(-)
>
> --
> 1.9.3
>