Re: Get versioned minsyms from dynamic symtab (Was: Re: How to call operator<< functions?)

[Frederic RISS <frederic.riss@st.com>]

On Thu, 2006-08-31 at 15:23 +0200, Frederic RISS wrote:
> On Thu, 2006-08-31 at 16:02 +0300, Michael Veksler wrote:
> > Take the two files from my test case in:
> >    http://sources.redhat.com/ml/gdb/2006-08/msg00271.html
> > [...]
> > (gdb) p x.Print(std::cout)
> > Enter B::Print() this=0xbfffec00
> > $1 = void
> > (gdb) p x.Print(myCout)
> > Cannot resolve method B::Print to any overloaded instance
> > (gdb) p x.Print(std::cout)
> > Cannot resolve method B::Print to any overloaded instance
> > (gdb)
> > ==============
> > What is going on here. Why the second Print(std::cout) no longer works?
> > Let's try to rerun without exiting GDB:
> 
> Sorry, I can't reproduce that... this is working fine here. 

In fact I managed to reproduce this behavour using a libstdc++ compiled
without debug information. What's happening is quite strange, and it
might very well be a GCC bug and not a GDB one.

What happens is that you get 2 definitions of std::cout in the debug
information of your example. One definition for each file. The gotcha is
that neither of these definitions are complete. They're just empty
shells specifying that the symbol is of type 
``typedef  basic_ostream<char,std::char_traits<char> >  std::ostream''
without giving a clue to the debugger what this type is made of.
I think GCC should emit a complete type because you use std::ostream in
each of your files.

The first 'p x.Print(std::cout)' works because at this point, the
debugger has only read the full debug information of the first file.
This file contains a definition of std::cout and the definition of
B::Print which both point to the same instance of the std::ostream type.
Being the same instance, even if the type is incomplete GDB resolves the
overload correctly.
After you've referenced 'myCout' which is defined in the second file,
the debug info of the latter has been read, bringing a second definition
of std::cout in the global scope. This second definition is found by
further lookups of this symbol, and this time, the symbol type isn't the
same instance as before. GDB tries to compare to incomplete types and of
course it fails...

I thought that using -feliminate-dwarf2-dups would help, but it doesn't.

One thing we could do is to compare the TYPE_TAG_NAME for overload
resoltion if there's no type name. During my tests, it was set to
'std::basic_ostream<char,std::char_traits<char> >' but I've read some
comments stating that it shouldn't be used. Or maybe the bug is that we
don't fill TYPE_NAME with that information?