From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5827 invoked by alias); 8 Jan 2003 00:52:29 -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 5812 invoked from network); 8 Jan 2003 00:52:28 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 00:52:28 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18W6Kd-00072d-00; Tue, 07 Jan 2003 20:52:39 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18W4SC-0007uU-00; Tue, 07 Jan 2003 19:52:20 -0500 Date: Wed, 08 Jan 2003 00:52:00 -0000 From: Daniel Jacobowitz To: Sunil Alankar Cc: gdb@sources.redhat.com Subject: Re: GDB 5.2/5.3 breakpoint bug Message-ID: <20030108005220.GA30387@nevyn.them.org> Mail-Followup-To: Sunil Alankar , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00070.txt.bz2 On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote: > Hi, > > While debugging this in function, find_pc_sect_line (CORE_ADDR pc, struct > sec *section, int notcurrent) > I found there were two line items in a line table with the same value of PC. > First one gets picked as the best match. But this had item->line == 0. The > next line item with the same value for item->pc, but a valid item->line ( > > 0) does not get picked as the best match. > I put in the following check to correct this. My question is, > Is it valid to have have more than one line item with same value faor PC and > possibly 0 for line in one of them? What causes this? > Would this be an appropriate fix? Or is the problem more deep rooted in > creating the symbol table? I'll look at this more precisely later (tomorrow, I hope...) but what that means is that a function ends exactly where another one starts. Very interesting; we probably should ignore the ending marker in that case, but I'm not sure you're doing it the best way. > > --- ../original/gdb-5.3/gdb/symtab.c Thu Aug 29 20:24:00 2002 > +++ gdb-5.3/gdb/symtab.c Tue Jan 7 14:42:34 2003 > @@ -1950,6 +1950,21 @@ > best_end = 0; > } > > + /* Handle the case where the prev->pc == best->pc due to more than > one line > + items for a pc, but the best->line == 0. grab a better match if one > exists > + that has a non zero line number */ > + > + else if (prev && (!best || ((prev->pc == best->pc) && (best->line == > 0) > + && (prev->line != 0)))) > + { > + best = prev; > + best_symtab = s; > + > + /* Discard BEST_END if it's before the PC of the current BEST. */ > + if (best_end <= best->pc) > + best_end = 0; > + } > + > /* If another line (denoted by ITEM) is in the linetable and its > PC is after BEST's PC, but before the current BEST_END, then > use ITEM's PC as the new best_end. */ > > > -----Original Message----- > From: gdb-owner@sources.redhat.com > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar > Sent: Sunday, January 05, 2003 3:11 PM > To: Daniel Jacobowitz > Cc: gdb@sources.redhat.com > Subject: RE: GDB 5.2/5.3 breakpoint bug > > > Correction to the link for the systemc library sources: > > http://www.systemc.org/download.php/systemc/13/19/systemc-2.0.1.tgz > > Thx > > Sunil > > -----Original Message----- > From: gdb-owner@sources.redhat.com > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar > Sent: Sunday, January 05, 2003 3:07 PM > To: Daniel Jacobowitz > Cc: gdb@sources.redhat.com > Subject: RE: GDB 5.2/5.3 breakpoint bug > > > I guess the e-mail with the attachment of library and include files was not > delivered. Here it is without attachments. > The sources for the systemc library/include files are at > http://www.systemc.org/download.php/systemc/1/4/systemc-1.0.2.tar.gz > Sunil > > -----Original Message----- > From: Sunil Alankar [mailto:sunil.alankar@coware.com] > Sent: Sunday, January 05, 2003 2:48 PM > To: Daniel Jacobowitz > Cc: gdb@sources.redhat.com > Subject: RE: GDB 5.2/5.3 breakpoint bug > > > Hi, > I have a detailed description of the problem here. Hope this would help. I > appreciate your help. > > Thank you > > Sunil > > > Problem: > Unable to set class method breakpoints in solaris with gdb 5.3 while using > systemc > library in the program. > > Platform: > SunOS tesla 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4 > > g++ version: > Reading specs from > /eng/devtools/SunOS_5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs > gcc version 2.95.2 19991024 (release) > > gdb version: > GNU gdb 5.3 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.7". > > > Test program: > > This error occured while I am debugging a systemC (c++ library for system > design) program. > Here is a small example program that demonstrates the problem. ( I have > attached the > required library for solaris and include files with the e-mail) > > //------------------------------------------------------------- > #include > > SC_MODULE(top) > { > public: > > sc_in_clk iclk; > > void func() > { > printf ("."); > } > > SC_CTOR(top) > { > SC_METHOD(func); > sensitive_pos << iclk; > dont_initialize(); > } > }; > > int sc_main (int argc , char *argv[]) > { > sc_clock clk("clk", 20); > top *top1 = new top("Top1"); > top1->iclk(clk); > sc_start(20000); > return 0; > } > > //------------------------------------------------------------- > > Build the example with: > % g++ -g -I./include -L./ -lm test1.cpp -lsystemc -o tx > > %/home1/gdb-5.3/gdb/gdb tx > GNU gdb 5.3 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.7"... > (gdb) b top::func > the class top does not have any method named func > Hint: try 'top::func or 'top::func > (Note leading single quote.) > (gdb) > > > In some systemC programs, gdb attempts to set breakpoints at invalid > addresses. > > This works without a problem in gdb 5.1 with proper breakpoint being set. > > > > I hope this test case can provide sufficient ground to get at the problem. > > > > > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@mvista.com] > Sent: Friday, January 03, 2003 6:23 PM > To: Sunil Alankar > Cc: gdb@sources.redhat.com > Subject: Re: GDB 5.2/5.3 breakpoint bug > > > On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote: > > Hi, > > > > Attempting to set a class member function breakpoint (say break > > myClass::funcOne) fails to set a proper break point in solaris 2.7. > > This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody > > has any idea where to look?. I would appreciate any help. > > What _does_ happen if it isn't a proper breakpoint? Can you provide a > transcript? > > What version of what compiler are you using? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer