Re: catchpoint - bptype

[Aleksandar Ristovski <aristovski@qnx.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.
>