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

[Michael Veksler <mveksler@techunix.technion.ac.il>]

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