From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26765 invoked by alias); 3 Apr 2008 17:33:47 -0000 Received: (qmail 26748 invoked by uid 22791); 3 Apr 2008 17:33:47 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 17:33:28 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 4BD2F3BEAC; Thu, 3 Apr 2008 10:33:26 -0700 (PDT) Subject: Re: Multiple breakpoints From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org, gdb@sources.redhat.com In-Reply-To: <20080403140140.GA20986@caradoc.them.org> References: <18420.39684.185853.891083@kahikatea.snap.net.nz> <20080403131816.GA16695@caradoc.them.org> <20080403140140.GA20986@caradoc.them.org> Content-Type: text/plain Date: Thu, 03 Apr 2008 17:37:00 -0000 Message-Id: <1207244006.31772.164.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) 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/msg00030.txt.bz2 On Thu, 2008-04-03 at 10:01 -0400, Daniel Jacobowitz wrote: > On Thu, Apr 03, 2008 at 05:51:00PM +0400, Vladimir Prus wrote: > > Daniel Jacobowitz wrote: > > > > > On Thu, Apr 03, 2008 at 11:01:10AM +0200, Andreas Schwab wrote: > > >> TRY_CATCH expands to a loop, probably the loop condition has been > > >> duplicated by the compiler. > > > > > > I think we try to set only one breakpoint per containing function, > > > though. > > > > Uh-uh, you keep on telling this :-) > > Per *block*, not per function. > > Durn. Well, I would have thought the parts of a for loop were in the > same block, but I can see GCC deciding otherwise. The inside parts probably are, but there has to be loop block, and there has to be something outside the loop block to decide whether or not to repeat the loop block. If that made sense... ;-) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26766 invoked by alias); 3 Apr 2008 17:33:47 -0000 Received: (qmail 26749 invoked by uid 22791); 3 Apr 2008 17:33:47 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 17:33:28 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 4BD2F3BEAC; Thu, 3 Apr 2008 10:33:26 -0700 (PDT) Subject: Re: Multiple breakpoints From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org, gdb@sources.redhat.com In-Reply-To: <20080403140140.GA20986@caradoc.them.org> References: <18420.39684.185853.891083@kahikatea.snap.net.nz> <20080403131816.GA16695@caradoc.them.org> <20080403140140.GA20986@caradoc.them.org> Content-Type: text/plain Date: Thu, 03 Apr 2008 21:36:00 -0000 Message-ID: <1207244006.31772.164.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) 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/msg00031.txt.bz2 Message-ID: <20080403213600.kjaPKkyvi3QV1Q27WZFB_xRW_6BD14XcCYzt5pE6HdM@z> On Thu, 2008-04-03 at 10:01 -0400, Daniel Jacobowitz wrote: > On Thu, Apr 03, 2008 at 05:51:00PM +0400, Vladimir Prus wrote: > > Daniel Jacobowitz wrote: > > > > > On Thu, Apr 03, 2008 at 11:01:10AM +0200, Andreas Schwab wrote: > > >> TRY_CATCH expands to a loop, probably the loop condition has been > > >> duplicated by the compiler. > > > > > > I think we try to set only one breakpoint per containing function, > > > though. > > > > Uh-uh, you keep on telling this :-) > > Per *block*, not per function. > > Durn. Well, I would have thought the parts of a for loop were in the > same block, but I can see GCC deciding otherwise. The inside parts probably are, but there has to be loop block, and there has to be something outside the loop block to decide whether or not to repeat the loop block. If that made sense... ;-)