Re: catchpoint - bptype

[Aleksandar Ristovski <aristovski at qnx dot com>]

Daniel Jacobowitz wrote:
> On Mon, Apr 28, 2008 at 01:28:57PM -0400, Aleksandar Ristovski wrote:
> > I agree, but without knowing the long term intent it is hard to
> > tell. At the moment it introduces slight complication since only
> > "catch" and "throw" use ops and nothing else (and, therefore, take
> > different printing route than anything else). I can see how
> > breakpoint_ops can be very useful, if used consistently - it could
> > be used to, for example, get rid of the switch statements you
> > mentioned above.
>
> Why do you assume there is a long term intent? :-)

Just asking...

> I don't want to add new elements to those switches unless they are
> really for things that do not behave like breakpoints.  I'd be happy
> to see patches removing existing cases.  That's why, when I wrote new
> code to catch C++ exceptions, I used breakpoint_ops.

I think breakpoint_ops is a good approach, but I would dare to say - incomplete. 
> > See how "fork" is cool and "catch" isn't. "Catch" looks just like
> > any other breakpoint; the only diff. is in "What" field, while catch
> > fork is clearly a catchpoint.
>
> If you can convince us it matters, we can change the output.

Just that the documentation treats them differently and calls them catchpoints. And I would say that logically they are kind of special... that's all. 

> Personally I think "breakpoint on exception catch" is a perfectly
> reasonable thing to call it - that's what it is.  The fork catchpoints
> are not like a breakpoint, though, since they do not correspond to
> any code address - just an OS event.