From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13635 invoked by alias); 29 Nov 2012 19:34:44 -0000 Received: (qmail 12784 invoked by uid 22791); 29 Nov 2012 19:34:42 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 19:34:35 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qATJYNUn014671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 13:34:24 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 14:34:23 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 14:34:22 -0500 From: Marc Khouzam To: "'Pedro Alves'" , "'Yao Qi'" CC: "'dje@google.com'" , "'gdb-patches@sourceware.org'" Subject: RE: [PATCH 2/2] new tracepoint downloaded MI notification. Date: Thu, 29 Nov 2012 19:34:00 -0000 Message-ID: References: <1348793347-12556-1-git-send-email-yao@codesourcery.com> <1348793347-12556-3-git-send-email-yao@codesourcery.com> <20604.20455.105300.495734@ruffy2.mtv.corp.google.com> <509167D4.20007@redhat.com> <5091C0B0.5000508@codesourcery.com> <50AE6FCC.4020205@redhat.com> <50B7834B.3060508@codesourcery.com> <50B78675.4010505@redhat.com> In-Reply-To: <50B78675.4010505@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00893.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com]=20 > Sent: Thursday, November 29, 2012 11:00 AM > To: Yao Qi > Cc: Marc Khouzam; 'dje@google.com'; 'gdb-patches@sourceware.org' > Subject: Re: [PATCH 2/2] new tracepoint downloaded MI notification. >=20 > On 11/29/2012 03:46 PM, Yao Qi wrote: > > On 11/23/2012 02:32 AM, Pedro Alves wrote: > >> What about the case of connecting to a target that is=20 > tracing, after > >> disconnected tracing? Do we already tell the frontend=20 > somehow which > >> tracepoints are active on the target? Should tracepoints have an > >> "installed on target" field? > >> > >> Yao Qi wrote: > >>> >On 11/01/2012 03:09 AM, Marc Khouzam wrote: > >>>> >>Now that GDB pushes new tracepoints to the target=20 > immediately, that > >>>> >>use-case may not apply, but I wonder if there are=20 > other situations > >>>> >>where some tracepoints will be on the target and other=20 > will not? > >>> > > >>> >Yes, the pending tracepoints won't be downloaded after=20 > tracing is started until they are resolved. The notification=20 > is required for this case. > >> Ok. If the answer to my question above is yes, it might be this > >> notification ends up unnecessary in favor of a generic > >> =3Dbreakpoint-modified. > >=20 > > Pedro, to make sure I don't misread your comments, I'd like=20 > to ask are you suggesting that we can add an 'installed on=20 > target' field for tracepoint in '=3Dbreakpoint-modified' notification? >=20 > Well, sort of, but by side effect, since =3Dbreakpoint-modified=20 > includes all > the fields of a breakpoint/tracepoint. >=20 > Say you've set up a disconnected tracing session, and then disconnect. > Later, you start a new clean gdb session, create a new=20 > tracepoint (never > downloaded/installed on the target), and reconnect. At this=20 > point, GDB will fetch > the target's tracepoint list, and sync it with GDB's. The=20 > frontend gets > a =3Dbreakpoint-created for each of those uploaded tracepoints,=20 > but it has > no clue why they were created / their installed status. >=20 > You end up with some tracepoints that are installed, and some=20 > that aren't > in GDB's list. Does the frontend know this today by some=20 > means I'm missing? I think the frontend may be able to guess, when connecting to the target, that any tracepoint it did not create itself must be tracepoints already installed on target. However, this sounds a little risky and maybe prone to race-conditions. > If not, does fixing this mean adding an "installed" property to > breakpoints/tracepoints? Say we added your new notification,=20 > and then fixed the > above as I'm suggesting. At that point, this new tracepoint=20 > downloaded > notification ends up being redundant. >=20 > So I'm trying to get us to think with a broad perspective around > the "installed on target" frontend needs. I think Pedro's point is very good. It would be better to have=20 GDB actually report the "installed/not installed" state when=20 providing tracepoint info. Not only will it help in the disconnected-tracing case, but it will allow the frontend to refresh its state. Without it, any lost MI notification about tracepoint download, cannot be recovered from. IIUC, adding this entry the tracepoint info will also automatically cause a =3Dbreakpoint-modified notif when tracepoints are downloaded to the target. This is something the frontend still needs, as to=20 avoid forcing a refresh after any operation that could cause a tracepoint to be installed/un-installed. Thanks for bringing this point up! Marc