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] |
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
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
From bits/ostream.tcc header file: // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. // NB: This syntax is a GNU extension. #if _GLIBCXX_EXTERN_TEMPLATE extern template class basic_ostream<char>;
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.
Reading it more, one can force full instantiation of ostream: g++ -g -D_GLIBCXX_EXTERN_TEMPLATE=0 myCout.cpp cout-gdb.cpp Now everything works, and it is not that much bigger.
It sounds similar to the problem of GDB on AIX (with XCOFF). There is a PR on this: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.
-- Michael
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |