From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9105 invoked by alias); 8 Oct 2014 16:12:45 -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 9094 invoked by uid 89); 8 Oct 2014 16:12:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vc0-f180.google.com Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 08 Oct 2014 16:12:43 +0000 Received: by mail-vc0-f180.google.com with SMTP id le20so7055843vcb.11 for ; Wed, 08 Oct 2014 09:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Polr+B4pp3YlIqbLHBOu9RP3q4DqXVmLmlpOvaTIDYc=; b=Fqlp22D8kKTNk+EmSm/h0l2QJmYKwBCsPJ/TFoZsJk/nReJt/xavt9czdCTvSO7j6h dNMmllUeHvPDjnICmB20vcyAR1vQOS2dvoxuKEY9mKBkQKzWVj33Ezyv+4X9t2RHUXKR J9S+YVfZ9/QLuFTmrGrg1c2NQ+zsa5KJ40Kuhkn6URyZBpla/oZlDyyMNmN53LMVCpzI SvQzHTpYT9GM/qpRTW0biyaPRGgjIq2EvFfhmw/FQpxP1E8SgAg8lpCpB14gOmqhfzhr NYTIeIEN7qGaUGByfxiy531RyEn8LXKmUAdUizPlwhcfdAJA+TRy9oexV+Y6dRPFxais DFQg== X-Gm-Message-State: ALoCoQmzAMtebilLP5GM7FF480u9M9I3Bam/wWZZfVpxwxA1ENJup8wkvVON/KytF2Ah1opYmmHi MIME-Version: 1.0 X-Received: by 10.220.92.198 with SMTP id s6mr11705157vcm.38.1412784761290; Wed, 08 Oct 2014 09:12:41 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Wed, 8 Oct 2014 09:12:41 -0700 (PDT) In-Reply-To: <1412736678-2760-1-git-send-email-gabriel@krisman.be> References: <1412736678-2760-1-git-send-email-gabriel@krisman.be> Date: Wed, 08 Oct 2014 16:12:00 -0000 Message-ID: Subject: Re: [RFC PATCH 0/3] Catch syscall group From: Doug Evans To: Gabriel Krisman Bertazi Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00157.txt.bz2 On Tue, Oct 7, 2014 at 10:51 PM, Gabriel Krisman Bertazi 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. :-) > ). > > 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 >