From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1266 invoked by alias); 14 Feb 2006 03:25:21 -0000 Received: (qmail 1222 invoked by uid 22791); 14 Feb 2006 03:25:20 -0000 X-Spam-Check-By: sourceware.org Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Feb 2006 03:25:19 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1E3PHlR007073 for ; Mon, 13 Feb 2006 22:25:17 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1E3PF82237856 for ; Mon, 13 Feb 2006 22:25:17 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k1E3PFl2015279 for ; Mon, 13 Feb 2006 22:25:15 -0500 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k1E3PETT015256; Mon, 13 Feb 2006 22:25:14 -0500 Subject: Re: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com In-Reply-To: <20060210053352.GA11956@nevyn.them.org> References: <1138843590.1423.106.camel@dufur.beaverton.ibm.com> <20060202012733.GA19141@nevyn.them.org> <1139537659.1423.175.camel@dufur.beaverton.ibm.com> <20060210053352.GA11956@nevyn.them.org> Content-Type: text/plain Date: Tue, 14 Feb 2006 03:25:00 -0000 Message-Id: <1139887628.21920.116.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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-02/txt/msg00296.txt.bz2 On Fri, 2006-02-10 at 00:33 -0500, Daniel Jacobowitz wrote: > I wrote: > > On Thu, Feb 09, 2006 at 06:14:19PM -0800, PAUL GILLIAM wrote: > > On Wed, 2006-02-01 at 20:27 -0500, Daniel Jacobowitz wrote: > > > The patch is definitely wrong, as you suspected. We'd need to see a > > > testcase; it could be bogus, or partially missing, debug information. > > > Is the 'bad' breakpoint in a file with line numbers? > > That's still true; Paul, rather than poking around in the symbol > reader, I think we need to know how to reproduce this so that we can > understand what's going on. This code is all very fragile; without > some idea of what you're trying to fix I've got no idea if it's right > or not. I am working on trying to get together a small test case. In the mean time, here is a better description of what is going bad and why: There is a compilation unit that uses constructors/destructors for some class. There is a .text section for it in the executable, followed by '.gnu.linkonce...' sections for those constructors/destructors. Then there is a .text section for the compilation unit that contains the function we are trying to set a breakpoint on. Then comes a .text section for part of the implementation for that class. The high/low pc values for the compilation unit for that last .text section are not given in it's compilation unit DIE. GDB computes high/low pc values, but these are bogus because the code for the compilation unit is not contiguous. When GDB searches for the psymtab that contains the function where the breakpoint was set, it finds the wrong one because of these bogus high/low pc values. It then returns the 'best' sal from the wrong psymtab which has nothing to do with the function being breakpointed. I think the .opd think was a red herring. -=# Paul #=-