Re: psymtab/symtab error

Re: psymtab/symtab error

[Michael Elizabeth Chastain]

Paul Koning wrote:

> I don't know.  I ran into this with gcc 3.0.1, NetBSD i386 host,
> NetBSD MIPS target.

Yikes.  gcc 3.0.4 had many bugs with C++ debugging information,
particularly with templates.

And the symbol `_ZN9CFreeListI7CVolumeE6m_baseE' demangles to
`CFreeList<CVolume>::m_base', which is definitely a template
symbol (probably a member, from the name).

I am assuming here that your gcc 3.0.1 on NetBSD MIPS will have
about the same symbol table code as my gcc 3.0.4 on native
i686-pc-linux-gnu.

I recommend that you upgrade to gcc 3.1 or gcc 3.1.1 or gcc 3.2 or
gcc 3.2.1.  gcc 3.2.1 would be the best but any of them are much better
than gcc 3.0.4.  Eschew the CVS versions of gcc, they are not measurably
better than gcc 3.2.1 at this time and in some ways they are worse.

If you can't upgrade gcc, you can try building your whole program
with "-gdwarf-2" and see if that helps.  If that doesn't help any,
building the whole program with "-gstabs+" and see if that helps.
-gdwarf-2 is the best debugging format for C++, and -gstabs+ is
second best.

I don't know a simple reliable way to tell which is the default
on your platform.  I usually compile a small test program with
"gcc -S foo.c" and then read the foo.s file and look for the
telltale dwarf-2 or stabs+ information.  But regardless of what
the default debug format is, you can try setting the debug format
explicitly.

Michael C

Re: psymtab/symtab error

[Daniel Jacobowitz]

On Mon, Dec 16, 2002 at 08:15:37PM -0600, Michael Elizabeth Chastain wrote:
> Paul Koning wrote:
> 
> > I don't know.  I ran into this with gcc 3.0.1, NetBSD i386 host,
> > NetBSD MIPS target.
> 
> Yikes.  gcc 3.0.4 had many bugs with C++ debugging information,
> particularly with templates.
> 
> And the symbol `_ZN9CFreeListI7CVolumeE6m_baseE' demangles to
> `CFreeList<CVolume>::m_base', which is definitely a template
> symbol (probably a member, from the name).
> 
> I am assuming here that your gcc 3.0.1 on NetBSD MIPS will have
> about the same symbol table code as my gcc 3.0.4 on native
> i686-pc-linux-gnu.
> 
> I recommend that you upgrade to gcc 3.1 or gcc 3.1.1 or gcc 3.2 or
> gcc 3.2.1.  gcc 3.2.1 would be the best but any of them are much better
> than gcc 3.0.4.  Eschew the CVS versions of gcc, they are not measurably
> better than gcc 3.2.1 at this time and in some ways they are worse.
> 
> If you can't upgrade gcc, you can try building your whole program
> with "-gdwarf-2" and see if that helps.  If that doesn't help any,
> building the whole program with "-gstabs+" and see if that helps.
> -gdwarf-2 is the best debugging format for C++, and -gstabs+ is
> second best.

These options are not available with his tools versions; it's mdebug or
bust.  DWARF-2 didn't start working until 3.2 or so, and stabs until
binutils 2.12.1 or so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: psymtab/symtab error

[David Carlton]

On Mon, 16 Dec 2002 20:00:52 -0500, Paul Koning <pkoning@equallogic.com> said:
>>>>>> "David" == David Carlton <carlton@math.stanford.edu> writes:

David> I was reading through old saved emails and noticed this; what
David> debug format are you using?  

> I don't know.  I ran into this with gcc 3.0.1, NetBSD i386 host,
> NetBSD MIPS target.

Actually, now that I dig further, it probably doesn't matter: I think
we probably have this bug I was thinking of in all non-HP debug
formats.  Oops.

Anyways, if you could provide a test case (small is good but by no
means necessary), that would be great so I could see if your bug and
my bug are the same.

David Carlton
carlton@math.stanford.edu

Re: psymtab/symtab error

[Daniel Jacobowitz]

On Mon, Dec 16, 2002 at 08:00:52PM -0500, Paul Koning wrote:
> >>>>> "David" == David Carlton <carlton@math.stanford.edu> writes:
> 
>  David> On Thu, 14 Nov 2002 18:50:36 -0500, Paul Koning
>  David> <pkoning@equallogic.com> said:
>  >> 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?
> 
>  David> I was reading through old saved emails and noticed this; what
>  David> debug format are you using?  
> 
> I don't know.  I ran into this with gcc 3.0.1, NetBSD i386 host,
> NetBSD MIPS target.
> 
> Is there a tool that will tell me?

Try looking at the output of objdump -h.  If there are .stab/.stabstr,
then you're in STABS mode; if there are .debug_info sections, you're in
DWARF-2 most likely.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: psymtab/symtab error

[Paul Koning]

>>>>> "David" == David Carlton <carlton@math.stanford.edu> writes:

 David> On Thu, 14 Nov 2002 18:50:36 -0500, Paul Koning
 David> <pkoning@equallogic.com> said:
 >> 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?

 David> I was reading through old saved emails and noticed this; what
 David> debug format are you using?  

I don't know.  I ran into this with gcc 3.0.1, NetBSD i386 host,
NetBSD MIPS target.

Is there a tool that will tell me?

     paul

Re: psymtab/symtab error

[David Carlton]

On Thu, 14 Nov 2002 18:50:36 -0500, Paul Koning <pkoning@equallogic.com> said:

> 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?

I was reading through old saved emails and noticed this; what debug
format are you using?  Because I noticed a few weeks ago that the
DWARF 2 reader puts variables into the psymtab in their mangled form
rather than their demangled form (the latter is what it should do);
for various reasons, I don't expect that to normally cause problems,
but you might have run into a situation where it does matter.

Do you happen to have a small test case for this?  It would be great
if I could reproduce the problem, so I could see if my suspicions are
right or if it's something else unrelated.  Also, if you could file a
PR for it, that would be great.

David Carlton
carlton@math.stanford.edu

Re: psymtab/symtab error

[Paul Koning]

>>>>> "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

Re: psymtab/symtab error

[Jim Blandy]

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.

psymtab/symtab error

[Paul Koning]

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?

    paul