From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18518 invoked by alias); 30 Mar 2009 21:46:43 -0000 Received: (qmail 18510 invoked by uid 22791); 30 Mar 2009 21:46: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, 30 Mar 2009 21:46:38 +0000 Received: (qmail 31062 invoked from network); 30 Mar 2009 16:19:55 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Mar 2009 16:19:55 -0000 Message-ID: <49D0F125.6060609@codesourcery.com> Date: Mon, 30 Mar 2009 22:07:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Joel Brobecker CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: [PATCH] Make tracepoints into breakpoints References: <49CD275B.1020003@codesourcery.com> <20090330153348.GY9472@adacore.com> In-Reply-To: <20090330153348.GY9472@adacore.com> 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-03/txt/msg00694.txt.bz2 Joel Brobecker wrote: >> *************** bpstat_what (bpstat bs) >> *** 3324,3329 **** >> --- 3358,3367 ---- >> bs_class = bp_silent; >> retval.call_dummy = 1; >> break; >> + >> + case bp_tracepoint: >> + /* (should never occur, complain about it) */ >> + continue; >> } >> current_action = table[(int) bs_class][(int) current_action]; >> } >> > > This hunk looks really strange... Out of place? > The thing that caught my attention too was the comment that seem > to imply that this is a temporary comment, almost a FIXME. Not sure > if this is the case, but the complaint is not there (elsewhere maybe?). > I was waffling on whether to make explicit errors for the impossible cases. I suppose there should be, one can imagine a buggy target mistakenly stopping and reporting back at a tracepoint. >> + #if 0 /* names of commands not visible here, not clear if worth fixing */ >> + if (cmd_cfunc_eq (cmd, while_stepping_pseudocommand)) >> + indent = i2; >> + else if (cmd_cfunc_eq (cmd, end_actions_pseudocommand)) >> + indent = i1; >> + #endif >> > > Do we really want to keep this #if 0? I'd personally rather have > a comment. > Looking at this again, it would be easy enough just to make the two symbols visible, I'll do that. > I'd also like to look at your patch again sometime soon, to figure out > whether it'd make sense or not for tracepoints to have their own > breakpoint_ops routines... To be continued :) > I started out defining a breakpoint_ops, but it didn't seem like there was any good reason to fill in any of the fields. :-) Four of the fields are for the insert/hit/remove activity, which tracepoints don't participate in, and two are for printing, but tracepoints print out the same as regular breakpoints. Stan