Re: [RFC PATCH 2/3] Add support to catch groups of syscalls.

[Doug Evans <dje@google.com>]

On Wed, Oct 8, 2014 at 12:07 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> As I mentioned, you're doing this here because you have no way to know
> whether the user is asking to catch a syscall name or a group of
> syscalls.  This would be solved with my early proposal, of implementing
> the "-g" modifier on the catch syscall command.  It would also make the
> code simpler to follow here.

Yeah, let's agree on a syntax before we get through too many patch iterations.

Regarding:
> # catch syscalls write, read, chdir, and groups network and signal
> (gdb) catch syscall write read chdir -g network,signal
> # or maybe without comma-separated values for groups, to keep consistency
> (gdb) catch syscall write read chdir -g network signal

I dislike "network,signal" if we don't also accept "read,write".  I
gather the comma is there to remove ambiguity as to what "-g network
signal" means.
I also kinda dislike interpreting "-g" to mean all remaining arguments
(for a few reasons).
"catch syscall write -g network" feels clumsy if I can't also do
something like "catch syscall -g network -s write" or some such).

One could just say that syscall names and syscall group names share
the same namespace, but
I can imagine a system that happens to have a syscall that is the name
of a group on another system.
E.g., maybe there's a system where "signal" is a syscall.  It's a
logical name for the group.
Then if one happened to be unfortunate enough to work with two systems
where "signal" is a syscall name on one system and a group name on
another system, I can imagine tripping over the use of the same name
to mean different things and getting frustrated.

How about appending "-group" or some such to group names?

[I don't want to have too long a discussion or be too picky.
OTOH I also don't want to just pick something and then regret it.]