Re: psymtab/symtab error

[Jim Blandy <jimb@redhat.com>]

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?

Hmm.  Your sources have this entry in gdb/ChangeLog, right?

2002-08-29  Jim Blandy  <jimb@redhat.com>

	* symtab.c (lookup_symbol_aux): In the cases where we find a
	minimal symbol of an appropriate name and use its address to
	select a symtab to read and search, use `name' (as passed to us)
	as the demangled name when searching the symtab's global and
	static blocks, not the minsym's name.