From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23023 invoked by alias); 8 Jan 2003 19:22:09 -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 22654 invoked from network); 8 Jan 2003 19:20:25 -0000 Received: from unknown (HELO fw1.coware.com) (208.46.221.194) by 209.249.29.67 with SMTP; 8 Jan 2003 19:20:25 -0000 Received: from CoWare.com (coware1 [192.168.1.102]) by fw1.coware.com (8.11.6+Sun/8.11.4) with ESMTP id h08JK9e17489; Wed, 8 Jan 2003 11:20:09 -0800 (PST) Received: from gleekxp (dhcp209.coware.com [192.168.1.209]) by CoWare.com (8.11.1/8.11.4) with SMTP id h08JK8h15423; Wed, 8 Jan 2003 11:20:08 -0800 (PST) From: "Sunil Alankar" To: "Daniel Jacobowitz" , Subject: RE: GDB 5.2/5.3 breakpoint bug Date: Wed, 08 Jan 2003 19:22: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: <20030108181548.GA27461@nevyn.them.org> X-SW-Source: 2003-01/txt/msg00088.txt.bz2 -----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? 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. 2. Break point is incorrect even after specifying the full signature. Problem 2 goes away with my earlier workaround in gdb code. 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. for (sym = BLOCK_BUCKET (block, hash_index); sym; sym = sym->hash_next) { if (SYMBOL_DEMANGLED_NAME(sym)) if (SYMBOL_NAMESPACE (sym) == namespace && (mangled_name ? strcmp (SYMBOL_NAME (sym), mangled_name) == 0 : SYMBOL_MATCHES_NAME (sym, name))) { if (SYMBOL_DEMANGLED_NAME(sym)) return sym; } } return NULL; } ................... } Any thoughts? Thx Sunil