From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17619 invoked by alias); 30 Mar 2009 22:21:38 -0000 Received: (qmail 17388 invoked by uid 22791); 30 Mar 2009 22:21:36 -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 22:21:31 +0000 Received: (qmail 4964 invoked from network); 30 Mar 2009 22:21:29 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Mar 2009 22:21:29 -0000 Message-ID: <49D145DF.4040603@codesourcery.com> Date: Mon, 30 Mar 2009 23:01:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Make tracepoints into breakpoints References: <49CD275B.1020003@codesourcery.com> <20090330153348.GY9472@adacore.com> <49D10E0A.6000700@earthlink.net> <20090330220709.GC9472@adacore.com> In-Reply-To: <20090330220709.GC9472@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/msg00696.txt.bz2 Joel Brobecker wrote: > On Mon, Mar 30, 2009 at 11:23:06AM -0700, Stan Shebs wrote: > >> 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? >>> > > First of all, I apologize of this comment, since I realize now > that it was incorrect. I was completely confused because of the tabs > that made it look like you were putting a continue that would kill > the code just right after. If I had read the hunk more carefully, > I would have realized it was a '}', not a '{'! > Heh, it was a little strange-looking! > >> 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. >> > > Oh... I did not realize that this could actually happen if we had > a buggy target. Perhaps an error to help diagnose any problem, or > a complaint if we want to recover nicely from target errors? Just > some thoughts - I'm also fine if we prefer to recover silently. > > After looking at the execution flow some more, I decided to go with internal_error - bpstat_what is really a "computational" routine that needs to have meaningful bpstats going in - there's not a "makes no sense" alternative. So we'll expect higher-level infrun.c code to deal with tracepoints being reported back unexpectedly. (That code hasn't been written yet, but I'm sure I'll have a need for it soon. :-) ) Stan