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

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Dec 10, 2003 at 01:10:30PM -0500, Joel Brobecker wrote:
> 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);
> +

You may want to look in the archives for the breakpoint_ops and catch
exception patches I posted earlier this year; they're broader but do
essentially the same thing.

Personally I don't like this "language dependent breakpoint syntax"
idea.  Here's one reason why: judging from your implementation I bet
that a breakpoint on the starting instruction of the exception raising
function will cause this magic to happen.  With "catch exception" that
information is stored at a higher level, so you can break *0x08010102
and _not_ have GDB try to walk up a couple of frames.

Seems friendlier to me; I like to keep a line between GDB's
user-friendliness features and its abilities as a system debugger, for
when I'm trying to figure out why a language feature isn't working.

> > > 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

Hmm, that's quite nice.

> > 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.

Time will tell :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer