This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: catchpoint - bptype

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]