From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1792 invoked by alias); 2 Feb 2006 01:25:27 -0000 Received: (qmail 1774 invoked by uid 22791); 2 Feb 2006 01:25:25 -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; Thu, 02 Feb 2006 01:25:24 +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 k121PJLD017424 for ; Wed, 1 Feb 2006 20:25:19 -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 k121NM9M261178 for ; Wed, 1 Feb 2006 18:23:22 -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 k121PIjq018846 for ; Wed, 1 Feb 2006 18:25:18 -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 k121PIEx018815 for ; Wed, 1 Feb 2006 18:25:18 -0700 Subject: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: gdb-patches@sources.redhat.com Content-Type: text/plain Date: Thu, 02 Feb 2006 01:25:00 -0000 Message-Id: <1138843590.1423.106.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/msg00015.txt.bz2 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? 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 2 Feb 2006 00:57:52 -0000 @@ -2457,7 +2457,7 @@ /* For overlays, map pc back into its mapped VMA range */ pc = overlay_mapped_address (pc, section); } - sal = find_pc_sect_line (pc, SYMBOL_BFD_SECTION (sym), 0); + sal = find_pc_sect_line (pc, 0, 0); /* Check if SKIP_PROLOGUE left us in mid-line, and the next line is still part of the same function. */ ~