From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23492 invoked by alias); 5 Nov 2008 07:14:18 -0000 Received: (qmail 23386 invoked by uid 22791); 5 Nov 2008 07:14:16 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 07:13:40 +0000 Received: (qmail 13654 invoked from network); 5 Nov 2008 07:13:37 -0000 Received: from unknown (HELO guest-246.lvknet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Nov 2008 07:13:37 -0000 From: Vladimir Prus To: Stan Shebs Subject: Re: Tracepoint enhancements Date: Wed, 05 Nov 2008 07:14:00 -0000 User-Agent: KMail/1.9.10 Cc: Michael Snyder , "gdb@sources.redhat.com" References: <490B630F.8010008@codesourcery.com> <490F3F3C.4070104@vmware.com> <4910BBB1.3050800@codesourcery.com> In-Reply-To: <4910BBB1.3050800@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811051013.32620.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00033.txt.bz2 On Wednesday 05 November 2008 00:16:33 Stan Shebs wrote: > Michael Snyder wrote: > > Vladimir Prus wrote: > >> Michael Snyder wrote: > > > >>> One more thing, only vaguely related... > >>> > >>> I've thought that if we had the ability to attach an expression > >>> (in pcode such as we use for tracepoints) to a conditional breakpoint, > >>> we could have the conditional evaluation be done on the target > >>> rather than by gdb, which would be a big performance win for > >>> conditional breakpoints or watchpoints. > >> > >> Yes. We want conditional tracepoints, and the condition would have to= =20 > >> be evaluated > >> on the target. And if breakpoints and tracepoints are unified, both=20 > >> breakpoints and > >> tracepoints will benefit. > > > > Very good point. OK, you've convinced me. > I shall proceed on the assumption that we will make a tracepoint a kind=20 > of breakpoint. This means we no longer need the special=20 > enable/disable/delete commands. I think the original "trace" command=20 > should remain as-is, and I'm also inclined to leave "actions" alone for=20 > the moment, rather than try to merge with "commands"; while there could=20 > be some useful unification, it seems like more of a sweeping change to=20 > try to decide for every command, whether it could be part of a=20 > tracepoint action or not.=20 There's no need to do that. 'collect', 'while-stepping' and 'continue' can be part of command set that is hardware-supported. Other commands do no= t. >From MI standpoint, I disagree to having independent 'commands' and 'actio= ns' properties -- this makes no sense in the long run, and MI is not supposed to be breaking behaviour at random, so we cannot implement 'actions' now, and take it back later. > Ignore counts vs passcounts still mystify me a bit. They seem=20 > conceptually similar (modulo the sense inversion), but the documentation= =20 > for passcounts makes it seems as though one might expect all tracing and= =20 > all tracepoints to be disabled once a passcount is exceeded for any one=20 > of them - and I see where that might be the desired behavior, vs the=20 > per-breakpoint control of ignore counts. Yeah, this is one bit that needs further design. - Volodya