From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22412 invoked by alias); 17 Oct 2014 02:31:32 -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 22398 invoked by uid 89); 17 Oct 2014 02:31:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Fri, 17 Oct 2014 02:31:29 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9H2VQIP009464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 22:31:26 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9H2VP5r012060 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Oct 2014 22:31:26 -0400 From: Sergio Durigan Junior To: Pedro Alves Cc: "Jose E. Marchesi" , Doug Evans , gdb-patches@sourceware.org Subject: Re: [PATCH V2 3/9] New commands `enable probe' and `disable probe'. References: <1412961772-16249-1-git-send-email-jose.marchesi@oracle.com> <1412961772-16249-4-git-send-email-jose.marchesi@oracle.com> <21560.22449.803178.90104@ruffy2.mtv.corp.google.com> <878uknun2f.fsf@oracle.com> <5440649C.6080705@redhat.com> <54406623.2020802@redhat.com> X-URL: http://blog.sergiodj.net Date: Fri, 17 Oct 2014 02:31:00 -0000 In-Reply-To: <54406623.2020802@redhat.com> (Pedro Alves's message of "Fri, 17 Oct 2014 01:43:15 +0100") Message-ID: <87iojjfmv6.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/msg00452.txt.bz2 On Thursday, October 16 2014, Pedro Alves wrote: > This also raises the question, can't we have both a stap > probe and a dtrace probe with the name provider and name? Like, > using the proposed output that doesn't distinguish the probe types, > can't the user end up with the confusing: > > Provider Name Where Semaphore Enabled Object > demo am-main 0x0000000000400c96 n/a /home/jemarch/oracle/usdt/demo > demo am-main 0x0000000000400c8b n/a always /home/jemarch/oracle/usdt/demo > > Does GDB cope correctly with this? Will the user have > trouble specifying the probe he wants with the current UI? Aha, a good question :-P. Well, you can actually test this with current GDB, without even needing dtrace: (gdb) info probes Provider Name Where Semaphore Object test bla 0x00000000004004f4 a.out test bla 0x00000000004004f5 a.out (gdb) b -p bla Breakpoint 1 at 0x4004f4 (2 locations) You have basically two ways of specifying where the probe breakpoint is going to be located: either by using -probe (or -p), or using -probe-[type] (or -p[type]). The second way is not problematic, because you tell GDB that type you want explicitly, so there is no confusion. However, in the first way, you put a breakpoint in a "probe" (the type is not important here, only the probe name/provider). GDB will then try to see if any of the probe backends have probes with this name, and will put a breakpoint on every probe it finds (again, no matter which type). The logic for this is in gdb/probe.c:parse_probes, if you are interested. This is already working (as you can see in my example above), and Jose's patch does not touch it, so we are pretty much covered in this area. Nonetheless, I think it is a good idea to add one more field to the output of 'info probes', specifying the probe type. Thanks, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/