From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9008 invoked by alias); 29 Jun 2009 20:58:42 -0000 Received: (qmail 9000 invoked by uid 22791); 29 Jun 2009 20:58:42 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 20:58:37 +0000 Received: (qmail 13076 invoked from network); 29 Jun 2009 20:58:35 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Jun 2009 20:58:35 -0000 Message-ID: <4A492AF4.8080109@codesourcery.com> Date: Mon, 29 Jun 2009 20:58:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: [PATCH] Conditional tracepoints References: <4A45AE9B.9020400@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2009-06/txt/msg00849.txt.bz2 Tom Tromey wrote: >>>>>> "Stan" == Stan Shebs writes: >>>>>> > > Stan> This patch adds conditional tracepoints. Tracepoint conditions work > Stan> by being compiled into agent expressions that actually evaluate on the > Stan> spot in the target, rather than collecting blocks of trace data. > > Very cool. > > Now I'm wondering if we could use agent expressions for conditional > breakpoints somehow :-) > Certainly jimb didn't want to restrict agent expressions to just tracepoints. The messy part would be getting from trap hit to evaluator, since the usual native debugging arrangement gives control back to GDB right away. I suppose there is still a performance win if GDB does the effective equivalent of an inferior call to the evaluator after the trap is hit, 2-3 roundtrips is still better than 10-100. > Stan> As usual for tracepoints, GDB proper doesn't have to do much, > Stan> and most of the code here revolves around checking for the > Stan> "ConditionalTracepoints" feature, so as to maintain > Stan> compatibility with the two(?) existing tracepoint > Stan> implementations out there. > > Are either of these free software? > Yes, I was thinking of Nicholas McGuire's work, and Jim's Trac project. Probably no one would notice in real life, but I couldn't quite bring myself to make incompatible protocol changes without adding a feature test... > Stan> + > Stan> + struct agent_expr * > Stan> + gen_eval_for_expr (CORE_ADDR scope, struct expression *expr) > > Could use a header comment. > I agree. :-) > Stan> Index: tracepoint.c > [...] > Stan> + extern int remote_supports_cond_tracepoints (void); > > This seems fishy to me. > > At the very least I think this should be in a header, not in the .c > file. But... other cases like this seem to be expressed via target > methods, not as direct calls into remote.c. > I beg a little indulgence for the moment - the massive target vector change is coming in about ten patches or so. Since it touches everything in tracepoint.c, patches from before that change wouldn't even start to apply, so I'm recapitulating the order in which I wrote the pieces. In the process, we'll be seeing lots of places where the tracepoint code knows too much about the remote protocol code. Stan