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


Daniel Jacobowitz wrote:
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.

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.

It sounds similar to the problem of GDB on AIX (with XCOFF). There is a PR on this:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1170&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26cmd%3Dsubmit%2520query%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3DAIX%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26sortby%3DResponsible%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed%26.cgifields%3Doriginatedbyme%26.cgifields%3Dcolumns
It happens when debug information is ordered in a different way than GDB expects. This is something that native /bin/as does, and is not a fault of gcc. According to X-COFF spec, the assembler is allowed to do this reordering. I guess that this issue happens in different places GDB, but it still has similar sound - GDB is sensitive to the order it reads debug information.


--
Michael


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