[RFC PATCH 0/3] Catch syscall group

[Doug Evans]

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
>