From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3682 invoked by alias); 8 Jan 2003 22:46:06 -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 3538 invoked from network); 8 Jan 2003 22:45:56 -0000 Received: from unknown (HELO fw1.coware.com) (208.46.221.194) by 209.249.29.67 with SMTP; 8 Jan 2003 22:45:56 -0000 Received: from CoWare.com (coware1 [192.168.1.102]) by fw1.coware.com (8.11.6+Sun/8.11.4) with ESMTP id h08Mjje21361; Wed, 8 Jan 2003 14:45:45 -0800 (PST) Received: from notebook (dhcp212.coware.com [192.168.1.212]) by CoWare.com (8.11.1/8.11.4) with SMTP id h08Mjih22211; Wed, 8 Jan 2003 14:45:44 -0800 (PST) Message-ID: <00c201c2b767$a1b01060$d401a8c0@notebook> From: "Ching Lai" To: "Daniel Jacobowitz" Cc: "Nafees" , , "Cesar Quiroz" , "Sunil Alankar" References: <20030108204628.GA6776@nevyn.them.org> Subject: Re: GDB 5.2/5.3 breakpoint bug Date: Wed, 08 Jan 2003 22:46: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/msg00097.txt.bz2 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. db) x/320d &s->linetable.nitems 0x6debf0: 77 1667196020 3069 1667200366 0x6dec00: 0 1229376 3069 1701207922 .... 0x6df080: 0 1231068 1224 0 0x6df090: 0 1231080 1226 0 0x6df0a0: 0 1231080 1228 0 0x6df0b0: 0 1231152 0 0 0x6df0c0: 0 1231160 0 0 <================= pc 1231160 with line number 0 for sc_unsigned.h symbol 0x6df0d0: 0 0 795176551 762405167 0x6df0e0: 1667787118 1731159908 1647129902 841888046 gdb) p pc $37 = 1231164 <========= pc that we are looking for line number of a symbol gdb) p s->filename $38 = 0x6f54c0 "/eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatyp es/int/sc_unsigned.h" (gdb) p *s $39 = {next = 0x6f53b0, blockvector = 0x6f4578, linetable = 0x6debf0, block_line_section = 10, primary = 0, filename = 0x6f54c0 "/ eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatypes /int/sc_unsigned.h", dirname = 0x6df0d8 "/eng-qa/ching /gdb-5.2.1.inst/bin/", free_code = free_linetable, free_ptr = 0x0, nlines = 0, line_charpos = 0x0, language = language_cplus, debu gformat = 0x6f5520 "unknown", version = 0x0, fullname = 0x0, objfile = 0x28ca98} gdb) x/80d &s->linetable.nitems 0x6f4660: 14 0 8 0 0x6f4670: 0 114628 8 0 .... 0x6f46f0: 0 114740 5 0 0x6f4700: 0 1231160 5 0 <=============== another pc with the correct line number 5 for t.cpp symbol 0x6f4710: 0 1231168 6 0 0x6f4720: 0 1231184 7 0 0x6f4730: 0 1231192 0 0 0x6f4740: 0 1231200 0 0 0x6f4750: 0 0 795176551 762405167 0x6f4760: 1667787118 1731159908 1647129902 841888046 (gdb) p pc $41 = 1231164 (gdb) p s->filename $42 = 0x6f4630 "/eng-qa/ching/gdb-5.2.1.inst/bin/t.cpp" Does this make sense? Thanks. Ching ----- Original Message ----- From: "Daniel Jacobowitz" To: "Sunil Alankar" Cc: Sent: Wednesday, January 08, 2003 12:46 PM Subject: Re: GDB 5.2/5.3 breakpoint bug > On Wed, Jan 08, 2003 at 12:37:29PM -0800, Sunil Alankar wrote: > > Meanwhile, a colleague of mine had a different workaround: > > > > There is one extra record_line call in gdb 5.21 and gdb 5.3 which inserts > > extra line number > > and pc into the linetable of symtab entry. > > > > gdb/dbxread.c in gdb.5.1.01 > > 1919 if (*name == '\000') > > 1920 { > > 1921 /* This N_FUN marks the end of a function. This closes > > off the > > 1922 current block. */ > > 1923 within_function = 0; > > 1924 new = pop_context (); > > > > gdb/dbxread.c in gdb 5.2.1 > > 2749 if (*name == '\000') > > 2750 { > > 2751 /* This N_FUN marks the end of a function. This closes > > off the > > 2752 current block. */ > > 2753 record_line (current_subfile, 0, function_start_offset + > > valu); > > 2754 within_function = 0; > > 2755 new = pop_context (); > > 2756 > > > > gdb/dbxread.c in gdb 5.3 > > > > 2773 if (*name == '\000') > > 2774 { > > 2775 /* This N_FUN marks the end of a function. This closes > > off the > > 2776 current block. */ > > 2777 record_line (current_subfile, 0, function_start_offset + > > valu); > > 2778 within_function = 0; > > 2779 new = pop_context (); > > 2780 > > > > > > 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. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer >