From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11470 invoked by alias); 9 Jan 2003 03:40:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11434 invoked from network); 9 Jan 2003 03:40:06 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 9 Jan 2003 03:40:06 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18WVQQ-00017Q-00; Wed, 08 Jan 2003 23:40:18 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18WTY2-0002uM-00; Wed, 08 Jan 2003 22:40:02 -0500 Date: Thu, 09 Jan 2003 03:40:00 -0000 From: Daniel Jacobowitz To: Ching Lai Cc: Nafees , gdb@sources.redhat.com, Cesar Quiroz , Sunil Alankar Subject: Re: GDB 5.2/5.3 breakpoint bug Message-ID: <20030109034002.GC10532@nevyn.them.org> Mail-Followup-To: Ching Lai , Nafees , gdb@sources.redhat.com, Cesar Quiroz , Sunil Alankar References: <20030108204628.GA6776@nevyn.them.org> <00c201c2b767$a1b01060$d401a8c0@notebook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c201c2b767$a1b01060$d401a8c0@notebook> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00113.txt.bz2 On Wed, Jan 08, 2003 at 02:45:23PM -0800, Ching Lai wrote: > Hi Daniel, > > > > Comment out the line 2753 in gdb 5.21 and 2777 in gdb 5.3 and build > them > > on > > > solaris seems to work OK with two test cases. > > > > > > Now the question is to figure out why this line is added in gdb 5.21 > and > > > gdb 5.3? > > > > The line is supposed to be there; it's so we know what is and isn't > > inside a function. You need to explain better why it's causing a > > problem in find_pc_sect_line. > > The problem is the linetable in different symbol tables have the > same pc address in my testcase. One has valid number and the other one > with line number as 0 (which is added by the extra record_line()). > > In gdb 5.2.1 release of find_pc_set_line in symtab.c file. > > 1788 /* Is this file's best line closer than the best in the other > files? > 1789 If so, record this file, and its best line, as best so far. > */ > 1790 > 1791 if (prev && (!best || prev->pc > best->pc)) > 1792 { > 1793 best = prev; > 1794 best_symtab = s; > 1795 > 1796 /* Discard BEST_END if it's before the PC of the current > BEST. */ > 1797 if (best_end <= best->pc) > 1798 best_end = 0; > 1799 } > > Since the line 1791 prev->pc with valid line number is not greater than > best->pc > which has 0 as line number, so it did not pick up the correct symbol file. > > If the record_line is need in gdb 5.2.1 and gdb 5.3, then the line 1791 > might > need an extra condition to void picking up the wrong symbol table which has > line > number as 0 as added by record_line(). > > 1791 if (prev && (!best || prev->pc > best->pc) && (prev->line != 0)) > > > Here are the debugging section of my observation. Thanks for the extra detail. I see what's going on now; I believe this patch should also avoid the problem. Does it? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2002-03-08 Daniel Jacobowitz * symtab.c (find_pc_sect_line): Don't consider end-of-function lines. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.84 diff -u -p -r1.84 symtab.c --- symtab.c 2 Jan 2003 14:27:26 -0000 1.84 +++ symtab.c 9 Jan 2003 03:38:36 -0000 @@ -2012,9 +2012,11 @@ find_pc_sect_line (CORE_ADDR pc, struct the first line, prev will not be set. */ /* Is this file's best line closer than the best in the other files? - If so, record this file, and its best line, as best so far. */ + If so, record this file, and its best line, as best so far. Don't + save prev if it represents the end of a function (i.e. line number + 0) instead of a real line. */ - if (prev && (!best || prev->pc > best->pc)) + if (prev && prev->line && (!best || prev->pc > best->pc)) { best = prev; best_symtab = s;