This is the mail archive of the gdb-patches@sourceware.org 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: [RFC/RFA] Add support for catch Ada exceptions


> If possible, I'd like to have the same command work for both C++ and
> Ada in a mixed binary.  I don't think it's possible to throw exceptions
> between them yet, but I'm sure it's been talked about.
> 
> On the other hand, if this makes things too complex, we can postpone
> it.

I will admit that I do not follow compiler development too much even
within AdaCore. This idea itself rings a bell to me, but I also do not
think this is possible yet.

It would be nice indeed if the same command was able to handle exceptions
from both languages. I think that we should postpone this for a little
later, though. From what I've seen in the GDB code, we would need to
create breakpoints with multiple locations. I'm not quite comfortable
with that yet. But the biggest issue is that the Christmas break is now
over, and I won't have as much control on my time...

> This sounds an awful lot like "catch throw" and "catch catch" for C++.
> I realize you'll want different terms, but should we make them share
> a common mechanism?
[...]

That's true, it's probably completely like "catch throw" as you guessed.

We do want to use terms that will look natural to Ada programers, so we
are attached to "exception" and "assert". It's been a small battle
already to have Robert Dewar accept the compromise of using "catch"
instead of "break", as to him it conveys the wrong idea that gdb will
catch and therefore handle the exception. I am neutral on this issue,
and I don't think we want to rediscuss the name of the command anyway.
My point is that I do want to keep these terms unless they are completely
objectionable.

What we can do, however, when we are able to have the same command
handle both C++ and Ada exception is have one be the alias of the other.
That way, both C++ and Ada programers have a command that feels natural
to them.

> Also, is this more like "catch catch" or "catch throw"?  I think it's
> more like "catch throw" from your example, i.e. stops you at the
> raise site.  If so, the other alternative may be useful too (if there's
> any way to implement that in Ada).  If not, that's not a big deal.
> Depends on your exceptions implementation.

Implementing the equivalent of "catch catch" for Ada is not possible
at the moment, not using breakpoints. We do not have a marker we can
break on like you do in C++.

> As for the breakpoints, could you please check if you really need
> new bp_* constants?  It's hard to spot in the history of breakpoint.c,
> but when I implemented something similar for C++, I added a "virtual
> table" that let us mark the breakpoint as a normal bp_breakpoint,
> and that simplified the change a bit.  Search for
> handle_gnu_v3_exceptions.  You're already using the virtual table,
> I see.  I couldn't tell from the breakpoint.c changes quite why
> you needed new bp constants.  I guess avoiding printing
> the condition might be one reason?

Reviewing my patch with this question in mind, I am starting to understand
how good a suggestion that is. I am still unsure whether I need new
constants or not, but even if I have to keep them, your suggestion already
allowed me to notice several simplifications. So thanks!

What happened over the few days I took to implement this is that
the breapoint location type I started using was bp_loc_other, and
then started tweaking the code in breakpoint.c here and there to
handle my special breakpoint. It's only late in the implementation
that I realized that my catchpoint was in fact a breakpoint and that
it would probably help to identify the location as such. I did not
realize that I could simplify/remove some of my earlier changes...
These changes must have confused you.

> The existing cases for "bp_catch_catch" and "bp_catch_throw" date
> back to HP/UX, which used a rather different OS mechanism to intercept
> exceptions, I believe.  Treating them as normal breakpoints scales
> better and I think it will simplify the patch.

I will look into that today or tomorrow, and see if this is possible.

Hiding the condition is not a big deal. If needed, I can use a bit
from the breakpoint flag, don't you think. The other change that we
might have to accept is that "info break" will display the catchpoint
as a "breakpoint", but I don't think this is an issue. I see you already
do that for catch/throw catchpoints. This would in fact make the GPS
team very happy, I believe. GPS is our development environment and it
contains a GUI for GDB. At the moment, it has serious hicups when
parsing the new bptypes ;-).

Thanks a lot for the very useful feedback. Will come back with another
patch hopefully soon.

-- 
Joel


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