From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4255 invoked by alias); 6 Jan 2006 14:19:11 -0000 Received: (qmail 4241 invoked by uid 22791); 6 Jan 2006 14:19:10 -0000 X-Spam-Check-By: sourceware.org Received: from svr68.ehostpros.com (HELO svr68.ehostpros.com) (67.15.48.48) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 14:19:08 +0000 Received: from [61.11.18.135] (helo=titan.linsyssoft.com) by svr68.ehostpros.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EusQo-000098-Fc; Fri, 06 Jan 2006 06:19:03 -0800 Received: from pythagoras.linsyssoft.com (pythagoras [192.168.1.3] (may be forged)) by titan.linsyssoft.com (8.13.1/8.13.1) with ESMTP id k06E5mSG004961; Fri, 6 Jan 2006 19:35:48 +0530 From: Amit Kale To: Daniel Jacobowitz Subject: Re: Breakpoints in constructors Date: Fri, 06 Jan 2006 14:19:00 -0000 User-Agent: KMail/1.8 Cc: GDB patches References: <200601031835.45731.amitkale@linsyssoft.com> <200601061856.39161.amitkale@linsyssoft.com> <20060106134503.GB4796@nevyn.them.org> In-Reply-To: <20060106134503.GB4796@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601061948.57309.amitkale@linsyssoft.com> 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/msg00078.txt.bz2 On Friday 06 Jan 2006 7:15 pm, Daniel Jacobowitz wrote: > On Fri, Jan 06, 2006 at 06:56:39PM +0530, Amit Kale wrote: > > I was not able to fix other failures though. The major one being a > > breakpoint on a statement in main causes three breakpoints to appear. > > It's because this statement is a call to a C++ inlined function. The > > expansion of inline function dodges the check in my patch for multiple > > breakpoints appearing for the same C statement when the statement is > > spread across multiple instructions interlaced with instructions from > > surrounding statements. I checked for function name, which would be the > > inline function name. That's why my check fails. Sigh, I wanted to send > > this patch again only after fixing this problem, but don't have any good > > ideas on how to do that. I'll very much appreciate if anyone has ideas > > about fixing this. > > The hack of checking whether they appear in the same function just > won't scale to fix this - possibly ever, but certainly not until inline > functions are represented properly in GDB's symbol table. Bad news. Any ideas about how to check whether multiple functions appear in the same function block? -Amit