From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21953 invoked by alias); 10 Feb 2006 05:33:56 -0000 Received: (qmail 21945 invoked by uid 22791); 10 Feb 2006 05:33:55 -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; Fri, 10 Feb 2006 05:33:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F7Qum-0003AR-Jc; Fri, 10 Feb 2006 00:33:52 -0500 Date: Fri, 10 Feb 2006 05:33: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: <20060210053352.GA11956@nevyn.them.org> Mail-Followup-To: PAUL GILLIAM , gdb-patches@sources.redhat.com References: <1138843590.1423.106.camel@dufur.beaverton.ibm.com> <20060202012733.GA19141@nevyn.them.org> <1139537659.1423.175.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1139537659.1423.175.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/msg00236.txt.bz2 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. > Here is another patch that 'fixes' the problem. > > In symtab.c(find_pc_sect_psymtab), we first see if we can find a symbol > in the minimal symbol table that contains the PC in the proper section. > If so, we make sure the PC is a text symbol. But in my case, the section > is '.opd' so we can't find a minimal symbol. First of all, why is the PC in .opd? Last time I looked at the PPC64 ABI, which was a while ago, .opd contained descriptors, not code. Are we actually executing code in .opd? How did it get there? Is there a partial symbol for the code we're executing (i.e. debug info)? All the code involving texthigh/textlow is a bit sketchy. Nowadays we could be recording precise ranges instead, in many cases; Jim posted a potential interface for that a year or two ago. Maybe that would fix your problem. I think that if your patch works, it's just getting lucky and will break some other case. -- Daniel Jacobowitz CodeSourcery