From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28032 invoked by alias); 15 Nov 2002 15:32:50 -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 27985 invoked from network); 15 Nov 2002 15:32:48 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 15 Nov 2002 15:32:48 -0000 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id gAFFWlW10214 for ; Fri, 15 Nov 2002 10:32:48 -0500 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id gAFFWl510205; Fri, 15 Nov 2002 10:32:47 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id gAFFWl900640; Fri, 15 Nov 2002 10:32:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15829.5022.638510.254046@pkoning.dev.equallogic.com> Date: Fri, 15 Nov 2002 07:32:00 -0000 From: Paul Koning To: jimb@redhat.com Cc: gdb@sources.redhat.com Subject: Re: psymtab/symtab error References: <15828.14028.345000.202128@gargle.gargle.HOWL> X-SW-Source: 2002-11/txt/msg00180.txt.bz2 >>>>> "Jim" == Jim Blandy writes: Jim> Paul Koning writes: >> Gentlepeople, >> >> I've been wading all over the guts of gdb for most of today, >> trying to track down the cause of this message: >> >> (gdb) info addr CFreeList::m_base Internal: global symbol >> `_ZN9CFreeListI7CVolumeE6m_baseE' found in iSCSIInit.cpp psymtab >> but not in symtab. _ZN9CFreeListI7CVolumeE6m_baseE may be an >> inlined function, or may be a template function (if a template, >> try specifying an instantiation: >> _ZN9CFreeListI7CVolumeE6m_baseE). (gdb) info addr >> CFreeList::m_base Symbol >> "_ZN9CFreeListI7CVolumeE6m_baseE" is static storage at address >> 0x4000dcf4. (gdb) >> >> I get this simply by invoking gdb and loading the symbol table of >> the image in question (a large RTOS application). >> >> I dove deep into the guts of symbol table processing without >> getting particularly enlightened. As a guess, perhaps the problem >> is that this symbol is entered into the symtab in its friendly >> form? >> >> The curious part is that (as shown above) reissuing the offending >> command makes it work right, i.e., the symbol is actually entered >> in the various gdb tables correctly so it can be found on the >> second attempt. >> >> I'm using gdb from the 5.3 branch, as of 9/30/02. Any hints? Jim> Hmm. Your sources have this entry in gdb/ChangeLog, right? Jim> 2002-08-29 Jim Blandy Jim> * symtab.c (lookup_symbol_aux): In the cases where we find a Jim> minimal symbol of an appropriate name and use its address to Jim> select a symtab to read and search, use `name' (as passed to us) Jim> as the demangled name when searching the symtab's global and Jim> static blocks, not the minsym's name. Yes, it does. All that text makes sense. I think the problem is that it isn't what's being done in the specific case I was looking at. When wading through the depths of symtab.c, I found that the specific call where the error message pops up is the recursive call at line 902: else if (MSYMBOL_TYPE (msymbol) != mst_text && MSYMBOL_TYPE (msymbol) != mst_file_text && !STREQ (name, SYMBOL_NAME (msymbol))) { /* This is a mangled variable, look it up by its mangled name. */ return lookup_symbol_aux (SYMBOL_NAME (msymbol), mangled_name, block, namespace, is_a_field_of_this, symtab); } There a lookup is being done on the name as it lives in the minsym table, which is the mangled one, and sure enough, that one can be found in psymtab but not in symtab... paul