From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3098 invoked by alias); 10 Feb 2006 02:12:43 -0000 Received: (qmail 3089 invoked by uid 22791); 10 Feb 2006 02:12:42 -0000 X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 02:12:42 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1A2Ceej030173 for ; Thu, 9 Feb 2006 21:12:40 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1A2AX47237190 for ; Thu, 9 Feb 2006 19:10:33 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1A2CeYZ031935 for ; Thu, 9 Feb 2006 19:12:40 -0700 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1A2CdQo031929; Thu, 9 Feb 2006 19:12:39 -0700 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: <20060202012733.GA19141@nevyn.them.org> References: <1138843590.1423.106.camel@dufur.beaverton.ibm.com> <20060202012733.GA19141@nevyn.them.org> Content-Type: multipart/mixed; boundary="=-PEa/lB4HuRS91g66UzAe" Date: Fri, 10 Feb 2006 02:12:00 -0000 Message-Id: <1139537659.1423.175.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 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/msg00233.txt.bz2 --=-PEa/lB4HuRS91g66UzAe Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 2501 On Wed, 2006-02-01 at 20:27 -0500, Daniel Jacobowitz wrote: > 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? > 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. Next, we look at all the partial symbol tables. If we find one, we want to make sure it's the best, so we scan the rest, starting with the one we found. But before we scan the rest of the partial symbol tables, we have to pass a couple of tests first. This patch removes the second of those tests which, in effect, said "If we didn't find a minimal symbol, then go with the first partial symbol table we found.' In the loop that scans the rest of the partial symbol tables, there is a "stop scanning now if we have a partial symbol that is an exact match for the minimal symbol we found earlier". This had to be altered so the test is only made if we *did* find a minimal symbol. What I am asking is why is the minimal symbol test I removed needed? Hopefully, the answer will help me understand the real cause of my bug. Thanks for all your help, -=# Paul #=- --=-PEa/lB4HuRS91g66UzAe Content-Disposition: attachment; filename=hope.patch Content-Type: text/x-patch; name=hope.patch; charset=utf-8 Content-Transfer-Encoding: 7bit Content-length: 1017 Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.146 diff -a -u -r1.146 symtab.c --- symtab.c 17 Dec 2005 22:34:03 -0000 1.146 +++ symtab.c 10 Feb 2006 01:39:41 -0000 @@ -746,9 +746,6 @@ section == 0) /* can't validate section this way */ return (pst); - if (msymbol == NULL) - return (pst); - /* The code range of partial symtabs sometimes overlap, so, in the loop below, we need to check all partial symtabs and find the one that fits better for the given PC address. We @@ -763,10 +760,14 @@ struct partial_symbol *p; p = find_pc_sect_psymbol (tpst, pc, section); + if (p != NULL + && msymbol != NULL && SYMBOL_VALUE_ADDRESS (p) == SYMBOL_VALUE_ADDRESS (msymbol)) + /* Return early if we found an exact match in the msymtab. */ return (tpst); + if (p != NULL) { /* We found a symbol in this partial symtab which --=-PEa/lB4HuRS91g66UzAe--