[rfc breakpoint] Catch exceptions

[Daniel Jacobowitz]

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