From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5344 invoked by alias); 8 Jan 2003 20:42:01 -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 5226 invoked from network); 8 Jan 2003 20:41:50 -0000 Received: from unknown (HELO fw1.coware.com) (208.46.221.194) by 209.249.29.67 with SMTP; 8 Jan 2003 20:41:50 -0000 Received: from CoWare.com (coware1 [192.168.1.102]) by fw1.coware.com (8.11.6+Sun/8.11.4) with ESMTP id h08Kfce19130; Wed, 8 Jan 2003 12:41:38 -0800 (PST) Received: from gleekxp (dhcp209.coware.com [192.168.1.209]) by CoWare.com (8.11.1/8.11.4) with SMTP id h08KfVh00398; Wed, 8 Jan 2003 12:41:31 -0800 (PST) From: "Sunil Alankar" To: "Sunil Alankar" , "Daniel Jacobowitz" Cc: Subject: RE: GDB 5.2/5.3 breakpoint bug Date: Wed, 08 Jan 2003 20:42:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-SW-Source: 2003-01/txt/msg00092.txt.bz2 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? Thx Sunil > -----Original Message----- > From: gdb-owner@sources.redhat.com > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar > Sent: Wednesday, January 08, 2003 11:36 AM > To: Daniel Jacobowitz > Cc: gdb@sources.redhat.com > Subject: RE: GDB 5.2/5.3 breakpoint bug > > > > > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@mvista.com] > Sent: Wednesday, January 08, 2003 11:32 AM > To: Sunil Alankar > Cc: gdb@sources.redhat.com > Subject: Re: GDB 5.2/5.3 breakpoint bug > > > On Wed, Jan 08, 2003 at 11:15:59AM -0800, Sunil Alankar wrote: > > > > > > -----Original Message----- > > From: Daniel Jacobowitz [mailto:drow@mvista.com] > > Sent: Wednesday, January 08, 2003 10:16 AM > > To: Sunil Alankar; gdb@sources.redhat.com > > Subject: Re: GDB 5.2/5.3 breakpoint bug > > > > > > On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote: > > > 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? > > > > > > When this happens, are the two lines in different files? > > > > I just can't get this to happen. If two items in a row have the same > > PC, we should never be picking the first of the two. > > > > > > I see two entries with the same PC in a line table. Wonder if > the problem > is > > in creation of the symbol table itself? > > Two entries with the same PC is not the problem; that's expected. > Choosing the first is a problem; I can't get the code to do that. I'll > look at what you sent me. > > > I came across another problem which may be related. In the following > > example, with gdb 5.3 on solaris: > > > > > > //------------------------------------------------------------- > > #include > > > > SC_MODULE(top) > > { > > public: > > > > sc_in_clk iclk; > > > > void func() > > { > > printf ("."); > > } > > > > SC_CTOR(top) > > { > > SC_METHOD(func); > > sensitive_pos << iclk; > > dont_initialize(); > > } > > }; > > > > //-------------------------------------------------------------- > > > > (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) b top::func(void) > > Breakpoint 1 at 0x1333a8 <<<<< incorrectly set > > > > > > There are two problems. > > 1. GDB can not set the bp without specifying the full signature. > > If you specify the full signature it uses a different search technique; > that's much more likely to work. This is still a bug. > > > 2. Break point is incorrect even after specifying the full signature. > > > > Problem 2 goes away with my earlier workaround in gdb code. > > We need to figure out why this is happening. > > > > While investigating problem 1, I found some mismatches in the scanning > > functions in symtab.c. > > > > lookup_block_symbol (register const struct block *block, const > char *name, > > const char *mangled_name, > > const namespace_enum namespace) > > { > > ............ > > if (BLOCK_HASHTABLE (block)) > > { > > unsigned int hash_index; > > hash_index = msymbol_hash_iw (name); > > hash_index = hash_index % BLOCK_BUCKETS (block); > > > > //<<<<< at this point I get a nr of buckets in the table 17, > > hash_index of 13 for the name > > //<<<<< We only search in the bucket of index 13 > > //<<<<< when I manually instrumented and inspected the > > //<<<<< block table, the required symbol (func__3top) is in > the bucket 6 > > and we miss it. > > What are name and mangled_name? I bet they're both func__3top. This > is a known bug and David's development branch contains a change which > fixes it for this particular case; current_language is probably C when > you start the search even though you're looking for a C++ symbol. > > I think the variable 'mangled_name' was null and 'name' was > func__3top (for > gdb command 'break top::func'). I would like to try the fix if > there is one > already. > > Thx > > Sunil > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer >