[0/2] more OO, Ada exception catchpoints: intro

[0/2] more OO, Ada exception catchpoints: intro

[Pedro Alves]

Continuing the catchpoints OO theme, Ada catchpoints are
mostly implemented in ada-lang.c, except for the corresponding
commands' themselves implementation, plus a couple of other
helpers.  In this mini-series, that builds on top of 
the series starting at
<http://sourceware.org/ml/gdb-patches/2011-06/msg00269.html>:

 - patch #1 moves the implementation and registration
   of the "catch exception/assert" commands to ada-lang.c.

 - patch #2 switches Ada catchpoints to the OO scheme
   similar to how other catchpoints have been converted in
   my previous series, and removes most of the knowledge about
   Ada catchpoints out of breakpoint.c (serving as proof/excuse
   for me to add a few more bits to breakpoint_ops and export
   a few functions from breakpoint.c :-) ).  The main benefit from
   the change, apart from making the code/design cleaner (IMO), is
   that this lifts the limitation that Ada catchpoints can't have
   user specified conditions.

(I think it might be nice even to move the whole bunch to
its own file (ada-lang.c is pretty big itself) afterwards,
though I'm not planning on doing that myself.)

No regressions on x86_64-linux (with an Ada runtime with debug info,
so that Ada catchpoints work).

Joel, WDYT?  Okay to apply?

(let me know if you'd like a combined patch make it
easier to test on your end)

-- 
Pedro Alves

Re: [0/2] more OO, Ada exception catchpoints: intro

[Joel Brobecker]

Hi Pedro,

> Joel, WDYT?  Okay to apply?

I looked at the changes, and I think that this is awesome work.
I wish I had time right now to test it in our environment, but
I am not sure I will.

I'm planning on doing a resync sometime early next week, so I'd
just go ahead and commit - I will fix whatever fallout there is
left.  And I'll look at simplifying the exception condition
handling a bit, since I think it will be cleaner to just get
the value of the parameter, and then compare it with the address
of the exception we want to stop on.

Thanks a lot, Pedro.
-- 
Joel

Re: [0/2] more OO, Ada exception catchpoints: intro

[Pedro Alves]

On Wednesday 22 June 2011 17:34:46, Joel Brobecker wrote:
> Hi Pedro,
> 
> > Joel, WDYT?  Okay to apply?
> 
> I looked at the changes, and I think that this is awesome work.

Thanks.

> I wish I had time right now to test it in our environment, but
> I am not sure I will.
> 
> I'm planning on doing a resync sometime early next week, so I'd
> just go ahead and commit - I will fix whatever fallout there is
> left.  

Okay, done.  (I just did a couple cosmetic changes to patch #2
before applying.)

> And I'll look at simplifying the exception condition
> handling a bit, since I think it will be cleaner to just get
> the value of the parameter, and then compare it with the address
> of the exception we want to stop on.

Might be a good idea.

> Thanks a lot, Pedro.

Welcome.

-- 
Pedro Alves

Re: [0/2] more OO, Ada exception catchpoints: intro

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> (serving as proof/excuse for me to add a few more bits to
Pedro> breakpoint_ops and export a few functions from breakpoint.c :-)
Pedro> ).

As far as I'm concerned, you don't need an excuse to do this.
I think it would be best if all breakpoints had to use breakpoint_ops
and there were no switches in breakpoint.c, just indirect calls.

Tom

Re: [0/2] more OO, Ada exception catchpoints: intro

[Pedro Alves]

On Wednesday 22 June 2011 18:24:06, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> (serving as proof/excuse for me to add a few more bits to
> Pedro> breakpoint_ops and export a few functions from breakpoint.c :-)
> Pedro> ).
> 
> As far as I'm concerned, you don't need an excuse to do this.
> I think it would be best if all breakpoints had to use breakpoint_ops
> and there were no switches in breakpoint.c, just indirect calls.

Yeah!

Some things aren't easy to make fully breakpoint_ops'ed though.
Example, code that is switching on is_hardware_watchpoint/is_watchpoint
and compares breakpoints, or loops over "kinds" of breakpoints (watchpoints,
tracepoints/breakpoints).  Maybe those would still stay.  
I have a feeling that some of those operations that we do on
breakpoints currently should be done on locations alone (and we
should decouple breakpoints/bp_locations a bit more so that we don't need
to look at a location's owner.)  Just a hunch though, haven't thought
about it that much through.

-- 
Pedro Alves