From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10803 invoked by alias); 25 Mar 2003 16:14:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10787 invoked from network); 25 Mar 2003 16:14:04 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 25 Mar 2003 16:14:04 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18xsxK-0006vA-00; Tue, 25 Mar 2003 12:15:26 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18xr3h-00043G-00; Tue, 25 Mar 2003 11:13:53 -0500 Date: Tue, 25 Mar 2003 16:14:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc breakpoint] Catch exceptions Message-ID: <20030325161352.GA15528@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20030325030107.GA3889@nevyn.them.org> <3E807E37.8010409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E807E37.8010409@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00492.txt.bz2 On Tue, Mar 25, 2003 at 11:05:11AM -0500, Andrew Cagney wrote: > >I'm just looking for feedback on this patch. It's mostly complete except > >for some mass re-indenting that some of the changes would require; I'm not > >entirely happy with the design yet though, so I'm looking for comments. > > If you're not happy with a design, the best thing to do is toss it on a > branch where it can incubate a little. I know from experience that I don't have time to maintain a branch for something I'm just doing in my spare time; this isn't an important project. > >The basic idea is that these "catchpoints" are just normal breakpoints and > >should be handled as such. But we'd like to print them a little > >differently, for clarity. > > >Here's the interesting bit, from struct breakpoint: > > This is the more interesting bit: > > + enum {ep_normal, ep_gnuv2, ep_gnuv3} ep_type; > > You're expecting multiple implementations ... That should actually be replaced with something opaque. Meant to fix that, oops. They'll be mostly the same, but the code for conditional stops will be different. > >+ enum print_stop_action (*print) (struct breakpoint *); > >+ > >+ void (*print_one) (struct breakpoint *, CORE_ADDR *); > >+ > >+ void (*print_mention) (struct breakpoint *); > > Per frame-unwind, instead put these virutal methods in their own struct > and then point the breakpoint at it. Separate v2 and v3 catchpoints (in > separate files?) will then be possible (and make the enum unnecessary). OK, good idea. Separate files is possible but seems unlikely to happen. > Long term, the `breakpoint' code should do everything via these virtual > methods. If a breakpoint is hit, the corresponding handler should be > called. Yes, that's my hope. Practical? Maybe. > Those methods should rely on zero globals - pass everything in. I think that's the case, I'll recheck. > Some nits: > > Just write this: > + (*b->print_mention) (b); > like: > b->print_mention (b) > While I know some kernel groups like to use that style, GDB doesn't > appear to. OK; I prefer the former style but it doesn't really matter. > This, and related, should be submitted separatly: > +extern struct symtab_and_line find_msymbol_start_sal (struct > minimal_symbol *, > + int); > > Any chance of a comment? Sure. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer