From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3433 invoked by alias); 2 Nov 2012 15:46:57 -0000 Received: (qmail 3425 invoked by uid 22791); 2 Nov 2012 15:46:56 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Nov 2012 15:46:47 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA2Fkhta018986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 11:46:44 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA2FkgYs014529; Fri, 2 Nov 2012 11:46:43 -0400 Message-ID: <5093EAE2.4090301@redhat.com> Date: Fri, 02 Nov 2012 15:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] new tracepoint downloaded MI notification. References: <1348793347-12556-1-git-send-email-yao@codesourcery.com> <1348793347-12556-3-git-send-email-yao@codesourcery.com> <5065E1E9.5040204@redhat.com> <5065E292.4000606@redhat.com> <506701EC.7040703@codesourcery.com> <509166FD.3050805@redhat.com> <5091C383.1080705@codesourcery.com> In-Reply-To: <5091C383.1080705@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-11/txt/msg00045.txt.bz2 On 11/01/2012 12:34 AM, Yao Qi wrote: > On 11/01/2012 01:59 AM, Pedro Alves wrote: >>> From the frontend's point of view, {number, location number} is better, and the schema "number.location_number" has been used in "=breakpoint-modified" notification. However, if we want to use {number, location number} here, we have to guarantee that the location number is an attribute of bp_location, because: >> This is not a particular issue of tracepoint locations, so, if it was a problem, it >> would be a problem for the existing notifications and MI commands as well. >> >> IOW, this would need to be fixed for all those other cases that expose location >> numbers, not just come up with an ad hoc solution. >> > > I agree. > >> IOW, there's no good justification for deviating this notification from >> existing practice. >> > > What do you mean by "existing practice"? Is {number, location number} the "existing practise"? Almost. AFAICS, the existing practice is "bp_number.loc_number" in MI, just like in the CLI. &"b main\n" ~"Breakpoint 8 at 0x457aab: main. (2 locations)\n" =breakpoint-created,bkpt={number="8",type="breakpoint",disp="keep",enabled="y",addr="",times="0",original-location="main"},{number="8.1",enabled="y",addr="0x0000000000457aab",func="main",file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="29"},{number="8.2",enabled="y",addr="0x0000000000457aab",func="main",file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="29"} ^done Note 'number="8.1"'. Or, (gdb) -break-disable 9.1 ^done (gdb) info breakpoint &"info breakpoint\n" ~"Num Type Disp Enb Address What\n" ~"9 tracepoint keep y \n" ~"9.1 n 0x0000000000457aab in main at ../../src/gdb/gdb.c:29 inf 1\n" ~"9.2 y 0x0000000000457aab in main at ../../src/gdb/gdb.c:29 inf 2\n" Looks like a =breakpoint-modified notification is missing for this, BTW: disable 8.1 &"disable 8.1\n" ^done (gdb) While this emitted the notification: disable 8 &"disable 8\n" =breakpoint-modified,bkpt={number="8",type="breakpoint",disp="keep",enabled="n",addr="",times="0",original-location="main"},{number="8.1",enabled="n",addr="0x0000000000457aab",func="main",file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="29"},{number="8.2",enabled="y",addr="0x0000000000457aab",func="main",file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="29"} ^done (gdb) >>> >In short, if we can make location number persistent (unchanged for a given bp_location object), then {number, location number} is fine, otherwise, I'd prefer {number, address}. >> {number, address} may looks stabler, but not even that is completely stable. >> Change the program's code a little, recompile, reload symbols, and you'll see the >> address change. Whatever smarts you'd want the frontend to have to track >> locations, GDB could do instead, once for all frontends, and better, because > ^^^^^^^^^ > IIUC, "locations" here mean location address instead of location number. I mean location as the abstract location a bp_location represents. By track, I mean, recognize that a given location is the same as another location (remember that catchpoints often don't even have a concept of address!). > >> it may use properties other than the address to decided whether a new instance >> of a location is logically the same as the old one (think of stap probes or static >> tracepoints, where the address is really a very low target side detail; or just >> consider line number instead of address). I think all this goes hand in hand with >> redesigning how GDB handles breakpoint re-setting (or rather, get rid of re-setting as is), >> which will make this whole stabler locations issue better. Keith will be going to >> work on that very soon, IIUC. > > FAOD, we should continue to use {number, location number}, and it requires improvement of breakpoint re-setting, correct? Yes. Though AFAICS, current notifications and commands use 'number="N.M"', not '{number, location number}'. -- Pedro Alves