From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25097 invoked by alias); 1 Jan 2007 04:42:26 -0000 Received: (qmail 25089 invoked by uid 22791); 1 Jan 2007 04:42:25 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Jan 2007 04:42:18 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 8956D48CE4B for ; Sun, 31 Dec 2006 23:42:16 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27999-01-4 for ; Sun, 31 Dec 2006 23:42:16 -0500 (EST) Received: from takamaka.act-europe.fr (AStDenis-105-1-75-95.w80-8.abo.wanadoo.fr [80.8.212.95]) by nile.gnat.com (Postfix) with ESMTP id B423848CC13 for ; Sun, 31 Dec 2006 23:42:14 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 0210434C099; Mon, 1 Jan 2007 08:43:01 +0400 (RET) Date: Mon, 01 Jan 2007 04:42:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] Add support for catch Ada exceptions Message-ID: <20070101044301.GF3428@adacore.com> References: <20061230032111.GB27642@adacore.com> <20061231213707.GA26604@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061231213707.GA26604@nevyn.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00009.txt.bz2 > If possible, I'd like to have the same command work for both C++ and > Ada in a mixed binary. I don't think it's possible to throw exceptions > between them yet, but I'm sure it's been talked about. > > On the other hand, if this makes things too complex, we can postpone > it. I will admit that I do not follow compiler development too much even within AdaCore. This idea itself rings a bell to me, but I also do not think this is possible yet. It would be nice indeed if the same command was able to handle exceptions from both languages. I think that we should postpone this for a little later, though. From what I've seen in the GDB code, we would need to create breakpoints with multiple locations. I'm not quite comfortable with that yet. But the biggest issue is that the Christmas break is now over, and I won't have as much control on my time... > This sounds an awful lot like "catch throw" and "catch catch" for C++. > I realize you'll want different terms, but should we make them share > a common mechanism? [...] That's true, it's probably completely like "catch throw" as you guessed. We do want to use terms that will look natural to Ada programers, so we are attached to "exception" and "assert". It's been a small battle already to have Robert Dewar accept the compromise of using "catch" instead of "break", as to him it conveys the wrong idea that gdb will catch and therefore handle the exception. I am neutral on this issue, and I don't think we want to rediscuss the name of the command anyway. My point is that I do want to keep these terms unless they are completely objectionable. What we can do, however, when we are able to have the same command handle both C++ and Ada exception is have one be the alias of the other. That way, both C++ and Ada programers have a command that feels natural to them. > Also, is this more like "catch catch" or "catch throw"? I think it's > more like "catch throw" from your example, i.e. stops you at the > raise site. If so, the other alternative may be useful too (if there's > any way to implement that in Ada). If not, that's not a big deal. > Depends on your exceptions implementation. Implementing the equivalent of "catch catch" for Ada is not possible at the moment, not using breakpoints. We do not have a marker we can break on like you do in C++. > As for the breakpoints, could you please check if you really need > new bp_* constants? It's hard to spot in the history of breakpoint.c, > but when I implemented something similar for C++, I added a "virtual > table" that let us mark the breakpoint as a normal bp_breakpoint, > and that simplified the change a bit. Search for > handle_gnu_v3_exceptions. You're already using the virtual table, > I see. I couldn't tell from the breakpoint.c changes quite why > you needed new bp constants. I guess avoiding printing > the condition might be one reason? Reviewing my patch with this question in mind, I am starting to understand how good a suggestion that is. I am still unsure whether I need new constants or not, but even if I have to keep them, your suggestion already allowed me to notice several simplifications. So thanks! What happened over the few days I took to implement this is that the breapoint location type I started using was bp_loc_other, and then started tweaking the code in breakpoint.c here and there to handle my special breakpoint. It's only late in the implementation that I realized that my catchpoint was in fact a breakpoint and that it would probably help to identify the location as such. I did not realize that I could simplify/remove some of my earlier changes... These changes must have confused you. > The existing cases for "bp_catch_catch" and "bp_catch_throw" date > back to HP/UX, which used a rather different OS mechanism to intercept > exceptions, I believe. Treating them as normal breakpoints scales > better and I think it will simplify the patch. I will look into that today or tomorrow, and see if this is possible. Hiding the condition is not a big deal. If needed, I can use a bit from the breakpoint flag, don't you think. The other change that we might have to accept is that "info break" will display the catchpoint as a "breakpoint", but I don't think this is an issue. I see you already do that for catch/throw catchpoints. This would in fact make the GPS team very happy, I believe. GPS is our development environment and it contains a GUI for GDB. At the moment, it has serious hicups when parsing the new bptypes ;-). Thanks a lot for the very useful feedback. Will come back with another patch hopefully soon. -- Joel