From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14381 invoked by alias); 28 Apr 2008 17:29:19 -0000 Received: (qmail 14364 invoked by uid 22791); 28 Apr 2008 17:29:18 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 17:29:01 +0000 Received: from [10.42.100.129] (min.ott.qnx.com [10.42.100.129]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSP69JRZ; Mon, 28 Apr 2008 13:28:58 -0400 Message-ID: <48160959.2050404@qnx.com> Date: Mon, 28 Apr 2008 20:09:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 Newsgroups: gmane.comp.gdb.devel To: Joel Brobecker CC: gdb@sources.redhat.com Subject: Re: catchpoint - bptype References: <20080428162109.GE16574@adacore.com> In-Reply-To: <20080428162109.GE16574@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00239.txt.bz2 Message-ID: <20080428200900.1ijOYHoNfWdzWXyfVlkzD5HoYmE5pxn-jfoDEWACv3M@z> Joel Brobecker wrote: >> I see that bp_catch_catch and bp_catch_trhow were removed in Dec. 2007 and >> this confuses me a bit: what is the intention? To get rid of all >> bp_catch_*? > > I haven't looked at the implementation of the other catchpoints, but > when I implemented Ada exception catchpoints, I really appreciated > the new infrastructure which allowed me to use bp_breakpoint instead > of having to add my own new bp_catchpoint enums (I tried the latter > first). It allowed me to basically implement the functionality in > a couple of functions instead of littering "case bp_catchpoint_exception..." > everywhere in breakpoint.c. This is where breakpoint_ops could be used... but I first want to understand the intent and what conceptually makes more sense, and then we can talk about the implementation details. > > I am not sure about the long term intentions in this area. I think > that the new approach based on breakpoint_ops can be extremely effective, I agree, but without knowing the long term intent it is hard to tell. At the moment it introduces slight complication since only "catch" and "throw" use ops and nothing else (and, therefore, take different printing route than anything else). I can see how breakpoint_ops can be very useful, if used consistently - it could be used to, for example, get rid of the switch statements you mentioned above. > I don't understand why you think that not having their own bp_catch > enum makes them less equal than the others. Like I said above, it > certainly made the implementation more compact and easier to maintain. > At the user level, I don't think he's seeing much of a difference either. For example: (gdb) catch catch Catchpoint 2 (catch) (gdb) catch fork Catchpoint 3 (fork) (gdb) info b Num Type Disp Enb Address What 2 breakpoint keep y 0xb7f75896 exception catch 3 catch fork keep y (gdb) See how "fork" is cool and "catch" isn't. "Catch" looks just like any other breakpoint; the only diff. is in "What" field, while catch fork is clearly a catchpoint.