Re: [RFC] Unexpected automatic language switch - get_frame_language()

[Joel Brobecker <brobecker at gnat dot com>]

Hello Daniel,

> > Some additional information about "break exception". We have slightly
> > modified the handling of the "break" command when in ada mode to special
> > case "break exception". This places a breakpoint on a known GNAT runtime
> > routine that's called upon exception raise. That's more or less how
> > exception breakpoints are implemented for Ada.
> 
> This is really unfortunate.  I suppose you've released products that do
> this?

Yes. This actually was implemented even before I joing ACT which was
three years ago (time flies).

> Is there any way you could switch to something like "catch
> throw" / "catch catch" which GDB implements for C++ for the same
> functionality - though not very well yet.  Adding catch raise as an
> alias for catch throw if that's more Ada-appropriate would be easy.

It's funny you should ask this, because we actually internally raised
this question yesterday, while we were discussing something else.
Some of us felt that it was more appropriate to switch to "catch raise",
which others found "break exception" more natural. So we ended up
deciding to keep things as they are for now.

Your suggestion adds weight for the "catch" approach, so I will restart
the discussions internally. Independently of the user's perspective,
I think your suggestion will make the implementation much cleaner
(have a look at our GDB 5.3 sources at libre.act-europe.fr how we
rewrite the breakpoint location for breakpoint exceptions if you
are curious).

Before I start the discussion and maybe cause us to change our
implementation, what is the feeling of the GDB maintainers in
general. Suppose for instance that we would submit our current
implementation for inclusion, would it be approved, or refused?
Right now, here is our change against breakpoint.c relevant to this
functionality:

  - At the begining of break_command_1, we do:

+
+  /* Ada introduces some language-specific breakpoint syntax.  Translate
+     to equivalent vanilla breakpoints. */
+  addr_start = arg = ada_breakpoint_rewrite (arg, &break_on_exception);
+

  - There is also the special handling of this breakpoint. When such
    a breakpoint is hit, we print the exception name in the breakpoint
    message. Something like this:

    Breakpoint 1, CONSTRAINT_ERROR at file:line.

    So we added the following call in print_one_breakpoint() to
    that effect:

+  ada_print_exception_breakpoint_task (b);
+

> > For the user's convenience, when the breakpoint is hit, we automatically
> > go up the call stack until we find a "user frame" (meaning a frame which
> > has debug info and is not inside the GNAT runtime), and select that
> > frame. So the user usually sees the location where the exception was
> > raised, instead of the runtime machinery that triggers and handles the
> > exception raise.
> 
> Does the real frame show up in backtraces?

Yes, here is what happens when hitting an exception breakpoint:

Breakpoint 1, CONSTRAINT_ERROR at 0x08049457 in a () at a.adb:3
3          raise Constraint_Error;
(gdb) bt
#0  <__gnat_raise_nodefer_with_msg> (e=0x80548f8) at a-except.adb:863
#1  0x0804bdce in ada.exceptions.raise_with_location_and_msg (e=0x80548f8, 
    f=0x804fee7, l=3, m=0x80510cb) at a-except.adb:977
#2  0x0804bc7d in <__gnat_raise_constraint_error_msg> (file=0x804fee7, line=3, 
    msg=0x80510cb) at a-except.adb:853
#3  0x0804bee9 in <__gnat_rcheck_04> (file=0x804fee7, line=3)
    at a-except.adb:1041
#4  0x08049457 in a () at a.adb:3
#5  0x0804942d in main (argc=1, argv=(system.address) 0xbffffa14, 
    envp=(system.address) 0xbffffa1c) at b~a.adb:109

> What you're describing is what I tried to do for C++, but I couldn't
> get it to work right.  I'd love to unify this code.

Me too. As a matter of fact, I think there is a lot that Ada & C++ have
in common, but I know very little about C++, and I'd love to see the
code being shared between the two. There is the symbol stuff (like name
mangling, etc) that's currently under way, the handling of overloading, etc.

-- 
Joel