From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16236 invoked by alias); 3 Jan 2006 19:40:14 -0000 Received: (qmail 16225 invoked by uid 22791); 3 Jan 2006 19:40:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 03 Jan 2006 19:40:08 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ets0s-0003QJ-4U; Tue, 03 Jan 2006 14:40:06 -0500 Date: Tue, 03 Jan 2006 19:40:00 -0000 From: Daniel Jacobowitz To: Amit Kale Cc: GDB patches Subject: Re: Breakpoints in constructors Message-ID: <20060103194006.GA12898@nevyn.them.org> Mail-Followup-To: Amit Kale , GDB patches References: <200601031835.45731.amitkale@linsyssoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601031835.45731.amitkale@linsyssoft.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00014.txt.bz2 On Tue, Jan 03, 2006 at 06:35:45PM +0530, Amit Kale wrote: > Hi All, > > I've rebased the breakpoints in constructors patch to current cvs. It's > attached for reviews and a submission into mainline gdb after any > modifications/improvements as per gdb gurus' suggestions. > > I ran gdb testsuite with this patch and found several failures which were > absent in a cvs-built gdb. They are mainly related to "advance" command. I am > looking at the failures and trying to fix them. I'll send an update if I can > fix any of them. > > I'll very much appreciate any feedback for this. Hi Amit, and sorry for not getting back to you about this last time you posted it on gdb@. The short version is that I believe this is roughly the right approach, but not quite. I posted a work-in-progress patch some time ago that takes a slightly different approach: Date: Sun, 13 Mar 2005 19:38:24 -0500 From: Daniel Jacobowitz Subject: RFC: First stab at breakpoints in multiple locations You might want to take a look at that thread, if you haven't already, to see what I mean. The basic difference is that instead of "break Foo::Foo" setting multiple breakpoints, it would set only one breakpoint, but that breakpoint would be associated with multiple PC values. I can't really tell from your patch what cases you do handle or don't; do breakpoints on constructors by name work? How about by line number? -- Daniel Jacobowitz CodeSourcery