This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Aug 31, 2006 at 06:48:04PM +0200, Frederic RISS wrote:
> 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.

This is a deliberate choice on GCC's part, to reduce overly excessive
debug information.  There've been arguments about it in the past.  My
feeling is that we will end up with something like a -gfull argument
to force the extra information to be emitted.  GDB needs to work as
well as possible anyway.

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

This is a problem with GDB, that I've always been amazed we didn't
hit more often.  It's a very difficult problem and I don't really know
what we should be doing about it.  I don't know if there's a standard
term for this, but I've called it type unification in the past.

We need some way to figure out that these are the same type, to the
best of our knowledge.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]