From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1910 invoked by alias); 28 Apr 2008 18:02:09 -0000 Received: (qmail 1897 invoked by uid 22791); 28 Apr 2008 18:02:08 -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 18:00:04 +0000 Received: from [10.42.100.129] (dhcp-100-129.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 JSP69KTT; Mon, 28 Apr 2008 14:00:02 -0400 Message-ID: <481610A2.4030709@qnx.com> Date: Tue, 29 Apr 2008 17:05:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Joel Brobecker , gdb@sources.redhat.com Subject: Re: catchpoint - bptype References: <20080428162109.GE16574@adacore.com> <48160959.2050404@qnx.com> <20080428173754.GA4955@caradoc.them.org> In-Reply-To: <20080428173754.GA4955@caradoc.them.org> 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/msg00243.txt.bz2 Daniel Jacobowitz wrote: > 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? :-) Just asking... > > 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. I think breakpoint_ops is a good approach, but I would dare to say - incomplete. >> 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. Just that the documentation treats them differently and calls them catchpoints. And I would say that logically they are kind of special... that's all. > 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. >