[RFC] Unexpected automatic language switch - get_frame_language()
Wed Dec 10 18:20:00 GMT 2003
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
> - 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 :)
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches