From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8587 invoked by alias); 15 Oct 2004 14:52:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8516 invoked from network); 15 Oct 2004 14:52:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 15 Oct 2004 14:52:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CITQm-0007E5-6K; Fri, 15 Oct 2004 10:51:44 -0400 Date: Fri, 15 Oct 2004 14:52:00 -0000 From: Daniel Jacobowitz To: David Lecomber Cc: patches Subject: Re: RFC: The Constructor Breakpoint Issue Message-ID: <20041015145144.GB25188@nevyn.them.org> Mail-Followup-To: David Lecomber , patches References: <1097714229.11117.99.camel@localhost.localdomain> <1097847699.1773.81.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1097847699.1773.81.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00282.txt.bz2 On Fri, Oct 15, 2004 at 02:41:39PM +0100, David Lecomber wrote: > Morning all, > > I have reformatted this so it actually compiles - I hope... > > Unfortunately this patch busts a lot of test cases (about 30..). I > have discovered that it is being over-zealous in applying breakpoints > and need an expert to suggest solutions. > > The first broken example is gdb.base/display.c - there we have a for > loop. So, first line of the for loop (display.c:14) is at PC xxxxxx, > and also at xxxxxx + some no. which presumably is where the increment > part of the for loop occurs. Do we want to get both these addresses for > breakpoints, or not.. because it happens.. > > I see the intel compiler sets the default is_stmt field to zero, and > never does anything else with it, and the GNU compilers set it to 1. > However, dwarf2read ignores this info anyway. Yes; I've been thinking on and off about fixing this for the GNU compilers. > I cannot see anything in the dwarf2 line info that enables us to > distinguish between the two cases - those where the lines are not really > duplicate, and those that are. I think everyone would find fixing this > issue important.. > > Opinions?? You can't tell from the line table. You can tell if you have both a line table and a .debug_info section; in the case that is interesting to you, the two PCs will be in different DW_TAG_subprogram trees. Given the order in which we parse things I'm not sure if you'll be able to check that easily. I don't much like the idea of your hack. However, since no one has had the time for a thorough fix _still_, if you can get it to work, it may be a good idea. I haven't looked at your implementation yet, though. -- Daniel Jacobowitz