From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1096 invoked by alias); 8 Jan 2003 19:43:20 -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 638 invoked from network); 8 Jan 2003 19:40:36 -0000 Received: from unknown (HELO fw1.coware.com) (208.46.221.194) by 209.249.29.67 with SMTP; 8 Jan 2003 19:40:35 -0000 Received: from CoWare.com (coware1 [192.168.1.102]) by fw1.coware.com (8.11.6+Sun/8.11.4) with ESMTP id h08JeNe17925; Wed, 8 Jan 2003 11:40:23 -0800 (PST) Received: from gleekxp (dhcp209.coware.com [192.168.1.209]) by CoWare.com (8.11.1/8.11.4) with SMTP id h08JeNh19105; Wed, 8 Jan 2003 11:40:23 -0800 (PST) From: "Sunil Alankar" To: "Daniel Jacobowitz" Cc: Subject: RE: GDB 5.2/5.3 breakpoint bug Date: Wed, 08 Jan 2003 19:43: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: <20030108193154.GA2257@nevyn.them.org> X-SW-Source: 2003-01/txt/msg00091.txt.bz2 -----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