From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7898 invoked by alias); 10 Dec 2003 19:16:15 -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 7891 invoked from network); 10 Dec 2003 19:16:14 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (205.232.38.116) by sources.redhat.com with SMTP; 10 Dec 2003 19:16:14 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2B8F847D62; Wed, 10 Dec 2003 14:16:14 -0500 (EST) Date: Wed, 10 Dec 2003 19:16:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Unexpected automatic language switch - get_frame_language() Message-ID: <20031210191614.GK1296@gnat.com> References: <20031205224807.GE716@gnat.com> <20031210174750.GA7669@nevyn.them.org> <20031210181030.GI1296@gnat.com> <20031210182008.GA21929@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031210182008.GA21929@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-12/txt/msg00301.txt.bz2 [quick reply before I run to catch my flight] > 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. Wildo. > 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. I don't think so, because we actually also added a field in the breakpoint structure that says whether the breakpoint is an exception breakpoint or not. So what happens is that we only try to walk up the stack only if that flag is set. I should have mentionned that in my previous message, my bad. Incidentally, this makes our change a bit more intrusive than it actually looks from my previous message. Given yours and Andrew's feedback, I am sold on the "catch" approach, but I need to discuss this within ACT. We do have a backward compatibilty problem, since this command has been used for a long time by our users, now... In any case, this is orthogonal to how this will be supported by the FSF version of GDB, so it's not something for you to worry about, our problem. > 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. Same for Ada exception breakpoints. > > 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. Thanks :) -- Joel