From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21676 invoked by alias); 9 Jan 2003 05:18:18 -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 21624 invoked from network); 9 Jan 2003 05:18:13 -0000 Received: from unknown (HELO fw1.coware.com) (208.46.221.194) by 209.249.29.67 with SMTP; 9 Jan 2003 05:18:13 -0000 Received: from CoWare.com (coware1 [192.168.1.102]) by fw1.coware.com (8.11.6+Sun/8.11.4) with ESMTP id h095I1e28720; Wed, 8 Jan 2003 21:18:01 -0800 (PST) Received: from shu ([192.168.0.2]) by CoWare.com (8.11.1/8.11.4) with SMTP id h095I0h00428; Wed, 8 Jan 2003 21:18:00 -0800 (PST) Message-ID: <001701c2b79e$787710e0$0200a8c0@shu> From: "Ching Lai" To: "Daniel Jacobowitz" Cc: "Nafees" , , "Cesar Quiroz" , "Sunil Alankar" References: <20030108204628.GA6776@nevyn.them.org> <00c201c2b767$a1b01060$d401a8c0@notebook> <20030109034002.GC10532@nevyn.them.org> Subject: Re: GDB 5.2/5.3 breakpoint bug Date: Thu, 09 Jan 2003 05:18:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-01/txt/msg00117.txt.bz2 Hi Daniel, Thanks for the quick response and the patch. Yes, the patch should fix the problem. I made the same change on my local copy of gdb 5.2.1 and it seems to work OK on my two test cases. I reported the problem in 11/25/02 to gdb bug report system with the bug tracking number 849. You should be able to close the bug. Thanks again for your help. Ching Reporter's email: ching@coware.com CC these people on PR status email: Number: 849 Category: gdb Synopsis: no break line when stop at member function of a class Confidential: no Severity: serious Priority: medium Responsible: unassigned State: open Class: sw-bug Submitter-Id: net Arrival-Date: Mon Nov 25 10:08:03 PST 2002 Closed-Date: Last-Modified: Originator: ching@coware.com Release: gdb5.2.1 Organization: Environment: solaris 2.7 Description: There is no break number displayed when you stop at member function of a class for gdb5.2.1. It only happens in Solaris version of gdb5.2.1. The linux version works OK. The previous version of solaris gdb 5.1 also works OK. So it must be something change from 5.1 to 5.2.1. It seems to stop at the correctly location, but just did not display the line number. /home/ching/testcase [tesla 6]>/eng- ----- Original Message ----- From: "Daniel Jacobowitz" To: "Ching Lai" Cc: "Nafees" ; ; "Cesar Quiroz" ; "Sunil Alankar" Sent: Wednesday, January 08, 2003 7:40 PM Subject: Re: GDB 5.2/5.3 breakpoint bug > 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;