Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: Doug Evans <dje@google.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
	 gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC PATCH 2/3] Add support to catch groups of syscalls.
Date: Mon, 20 Oct 2014 04:52:00 -0000	[thread overview]
Message-ID: <87oat7736y.fsf@anubis.Home> (raw)
In-Reply-To: <CADPb22TDAEWQraTHmabwvDCm8_rgzUpzBt1bu83k3uyHPx83jA@mail.gmail.com>	(Doug Evans's message of "Mon, 13 Oct 2014 09:49:35 -0700")

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]

Doug Evans <dje@google.com> writes:

Sorry I took so long to answer your message. I got a lot of college
stuff to deal with right now... :(

> Would you still allow "catch syscall open -g network"?

Yes.  As a matter of fact, I still don't see the problem of allowing
"catch syscall open -g network exit" to catch open and exit syscalls and
the network group on the same command, provided that -g refers only to
the next token.  By the way, for the "-group" suffix you suggested,
would we also allow "catch syscall open network-group exit", right?

> I'm not really comfortable with that (far more so than "catch syscall
> open network-group").
> If you want to require -g at the front, and thus disallow catching
> both syscalls and syscall groups in the same command then that would
> be fine with me.

I really think we shouldn't disallow catching syscalls and syscalls
group on the same command, no matter which syntax we pick.  GDB wiki
says that GDB should be more permissive about command's syntax, in a
sense that user shouldn't spend more time than needed to find out how a
command works.  I think disallowing catching syscalls and groups on the
same command would reduce expressiveness in this case.

> Still need a solution for listing them.  Arguably since we don't
> provide a way to list syscalls (sigh, modulo the hack I showed, which
> should be fixed so that it no longer works anyways :-)), providing a
> way to list syscall groups is for a separate patch.  Kudos if you
> still want to provide a way to list syscalls and groups though.

So, definitively allowing "catch syscall -g" to list syscalls is not a
good idea.  Sergio suggested off-list to use another option, maybe -lg
to list syscall groups.  Then, a future patch could also extend catch
syscall to list all syscalls using a -l option or something like that.
Sergio, sorry if I got your suggestion wrong.

OTOH, I might be over-thinking this simple stuff :).  I'm ok with the
namespace (suffix) syntax, but I think we should go with "g:" (or even
"group:network", if it's not too verbose) instead of "-group", to avoid
the issue pointed out by Sergio with the exit_group syscall.

Cheers,

-- 
Gabriel Krisman Bertazi

[-- Attachment #2: Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2014-10-20  4:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08  2:51 [RFC PATCH 0/3] Catch syscall group Gabriel Krisman Bertazi
2014-10-08  2:51 ` [RFC PATCH 1/3] Implemement support for groups of syscalls in the xml-syscall interface Gabriel Krisman Bertazi
2014-10-08 17:21   ` Sergio Durigan Junior
2014-10-08  2:51 ` [RFC PATCH 2/3] Add support to catch groups of syscalls Gabriel Krisman Bertazi
2014-10-08 19:07   ` Sergio Durigan Junior
2014-10-08 19:46     ` Doug Evans
2014-10-08 20:48       ` Sergio Durigan Junior
2014-10-12 21:37         ` Gabriel Krisman Bertazi
2014-10-12 22:52           ` Sergio Durigan Junior
2014-10-13 16:49           ` Doug Evans
2014-10-20  4:52             ` Gabriel Krisman Bertazi [this message]
2014-10-20 19:39               ` Sergio Durigan Junior
2014-10-27 19:20                 ` Doug Evans
2014-10-08  2:52 ` [RFC PATCH 3/3] Create syscall groups for x86_64 Gabriel Krisman Bertazi
2014-10-08 19:00   ` Sergio Durigan Junior
2014-10-08 16:10 ` [RFC PATCH 0/3] Catch syscall group Sergio Durigan Junior
2014-10-12 21:12   ` Gabriel Krisman Bertazi
2014-10-12 22:55     ` Sergio Durigan Junior
2014-10-08 16:12 ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oat7736y.fsf@anubis.Home \
    --to=gabriel@krisman.be \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox