From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22580 invoked by alias); 28 Apr 2008 17:42:38 -0000 Received: (qmail 22567 invoked by uid 22791); 28 Apr 2008 17:42:37 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 17:39:13 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 8E4B498278; Mon, 28 Apr 2008 17:37:55 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 30FA798149; Mon, 28 Apr 2008 17:37:55 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JqXIY-0001Ix-3E; Mon, 28 Apr 2008 13:37:54 -0400 Date: Mon, 28 Apr 2008 21:08:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: Joel Brobecker , gdb@sources.redhat.com Subject: Re: catchpoint - bptype Message-ID: <20080428173754.GA4955@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , Joel Brobecker , gdb@sources.redhat.com References: <20080428162109.GE16574@adacore.com> <48160959.2050404@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48160959.2050404@qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00241.txt.bz2 On Mon, Apr 28, 2008 at 01:28:57PM -0400, Aleksandar Ristovski wrote: > 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. Why do you assume there is a long term intent? :-) I don't want to add new elements to those switches unless they are really for things that do not behave like breakpoints. I'd be happy to see patches removing existing cases. That's why, when I wrote new code to catch C++ exceptions, I used breakpoint_ops. > (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. If you can convince us it matters, we can change the output. Personally I think "breakpoint on exception catch" is a perfectly reasonable thing to call it - that's what it is. The fork catchpoints are not like a breakpoint, though, since they do not correspond to any code address - just an OS event. -- Daniel Jacobowitz CodeSourcery