From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7751 invoked by alias); 4 Nov 2008 21:17:19 -0000 Received: (qmail 7622 invoked by uid 22791); 4 Nov 2008 21:17:19 -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; Tue, 04 Nov 2008 21:16:42 +0000 Received: (qmail 16511 invoked from network); 4 Nov 2008 21:16:40 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Nov 2008 21:16:40 -0000 Message-ID: <4910BBB1.3050800@codesourcery.com> Date: Tue, 04 Nov 2008 21:17:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Michael Snyder CC: Vladimir Prus , "gdb@sources.redhat.com" Subject: Re: Tracepoint enhancements References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> <490F3F3C.4070104@vmware.com> In-Reply-To: <490F3F3C.4070104@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00026.txt.bz2 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 >> be evaluated >> on the target. And if breakpoints and tracepoints are unified, both >> 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 of breakpoint. This means we no longer need the special enable/disable/delete commands. I think the original "trace" command should remain as-is, and I'm also inclined to leave "actions" alone for the moment, rather than try to merge with "commands"; while there could be some useful unification, it seems like more of a sweeping change to try to decide for every command, whether it could be part of a tracepoint action or not. We get tracepoint conditions via "condition" and "trace ... if" then. Not clear if "info tracepoints" should stick around as a subset of "info breakpoints". Ignore counts vs passcounts still mystify me a bit. They seem conceptually similar (modulo the sense inversion), but the documentation for passcounts makes it seems as though one might expect all tracing and all tracepoints to be disabled once a passcount is exceeded for any one of them - and I see where that might be the desired behavior, vs the per-breakpoint control of ignore counts. Stan