Re: psymtab/symtab error

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Jim" == Jim Blandy <jimb@redhat.com> writes:

 Jim> Paul Koning <pkoning@equallogic.com> 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<CVolume>::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<type>).  (gdb) info addr
 >> CFreeList<CVolume>::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 <jimb@redhat.com>

 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