From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14994 invoked by alias); 8 Oct 2014 20:48:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14985 invoked by uid 89); 8 Oct 2014 20:48:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Oct 2014 20:48:49 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s98Kmimv012280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 8 Oct 2014 16:48:44 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s98K63oG008122 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 8 Oct 2014 16:06:03 -0400 From: Sergio Durigan Junior To: Doug Evans Cc: Gabriel Krisman Bertazi , gdb-patches Subject: Re: [RFC PATCH 2/3] Add support to catch groups of syscalls. References: <1412736678-2760-1-git-send-email-gabriel@krisman.be> <1412736678-2760-3-git-send-email-gabriel@krisman.be> <87h9zebcsb.fsf@redhat.com> X-URL: http://blog.sergiodj.net Date: Wed, 08 Oct 2014 20:48:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 8 Oct 2014 12:46:18 -0700") Message-ID: <87siiy9vis.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00175.txt.bz2 On Wednesday, October 08 2014, Doug Evans wrote: > 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. Yeah. > I also kinda dislike interpreting "-g" to mean all remaining arguments > (for a few reasons). Since there are very few groups (compared to syscalls names), I also thought that "-g" could be used multiple times, like: (gdb) catch syscall -g network -g signal But... > "catch syscall write -g network" feels clumsy if I can't also do > something like "catch syscall -g network -s write" or some such). ... this comment also applies even if we consider "-g" to refer to the next argument. However, while I understand your feeling that having "-g" without having "-s" seems odd, I don't think I completely agree. I think that syscall groups are meta-information, and deserved to be treated differently. The command name "catch syscall" makes the user understand immediately what kind of argument the command expects (i.e., a syscall). It would be weird to make the user need to issue a "-s" to specify a syscall name. I am trying to think what would happen if we were talking about breakpoints and breakpoint groups. I think it would be fairly reasonable to have a syntax like: (gdb) break -g mygroup And not expect something like: (gdb) break -b function Do you see what I mean? > 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. Yes, that is the rationale behind my proposal. And I don't think syscall group names and syscall names share the same namespace, as explained above. > 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? Hm, it seems OK, but I am thinking about one specific syscall that might make things confusing here: exit_group(2). Consider: (gdb) catch syscall signal-group exit_group This can be very confusing for the user. > [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.] Yeah, I understand your reasons. Along the lines of your proposal above, I guess we can add a "g:" prefix to group names: (gdb) catch syscall read chdir g:network g:signal signal WDYT? -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/