From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15487 invoked by alias); 10 Dec 2003 18:20:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15475 invoked from network); 10 Dec 2003 18:20:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 10 Dec 2003 18:20:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AU8wU-00004q-5F; Wed, 10 Dec 2003 13:20:10 -0500 Date: Wed, 10 Dec 2003 18:20:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Unexpected automatic language switch - get_frame_language() Message-ID: <20031210182008.GA21929@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20031205224807.GE716@gnat.com> <20031210174750.GA7669@nevyn.them.org> <20031210181030.GI1296@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031210181030.GI1296@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00297.txt.bz2 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