From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2887 invoked by alias); 2 Feb 2006 01:27:39 -0000 Received: (qmail 2878 invoked by uid 22791); 2 Feb 2006 01:27:38 -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; Thu, 02 Feb 2006 01:27:38 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F4TG1-0004zq-RW; Wed, 01 Feb 2006 20:27:33 -0500 Date: Thu, 02 Feb 2006 01:27:00 -0000 From: Daniel Jacobowitz To: PAUL GILLIAM Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source Message-ID: <20060202012733.GA19141@nevyn.them.org> Mail-Followup-To: PAUL GILLIAM , gdb-patches@sources.redhat.com References: <1138843590.1423.106.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1138843590.1423.106.camel@dufur.beaverton.ibm.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-02/txt/msg00016.txt.bz2 On Wed, Feb 01, 2006 at 05:26:30PM -0800, PAUL GILLIAM wrote: > I ran across a problem where a breakpoint would be associated with the > wrong source. Not every breakpoint, just some breakpoints. And > changing the order of .o files on the link line would change which > breakpoints where affected. > > A 'bad' breakpoint would give the wrong source file and line number when > it was set. When the program was run and a bad breakpoint hit, the > wrong source would be shown by the break and by list. But the break > would, in fact, be at the right place. > > In debugging gdb, I narrowed it down (not the cause, just the failure) > to find_function_start_sal(). The call to find_pc_sect_line() was > finding the wrong sal. I noticed that the right sal was being found > earlier during the processing done by SKIP_PROLOGUE(). There, > find_pc_sect_line() was being called with a null section argument. > > This patch seems to "fix" the problem. But I don't feel comfortable > with it. > > Comments? 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? -- Daniel Jacobowitz CodeSourcery