From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13506 invoked by alias); 31 Aug 2006 19:48:51 -0000 Received: (qmail 13498 invoked by uid 22791); 31 Aug 2006 19:48:50 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw3.technion.ac.il (HELO mailgw3.technion.ac.il) (132.68.238.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Aug 2006 19:48:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id B6B85173CBF; Thu, 31 Aug 2006 22:48:44 +0300 (IDT) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wuyzniV7Ujtt; Thu, 31 Aug 2006 22:48:44 +0300 (IDT) Received: from techunix.technion.ac.il (techunix.technion.ac.il [132.68.1.28]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 6F68A173CBE; Thu, 31 Aug 2006 22:48:44 +0300 (IDT) Received: from [127.0.0.1] (techunix.technion.ac.il [132.68.1.28]) by techunix.technion.ac.il (Postfix) with ESMTP id DBB42149FC; Thu, 31 Aug 2006 22:48:43 +0300 (IDT) (envelope-from mveksler@tx.technion.ac.il) Message-ID: <44F73D1B.6010507@tx.technion.ac.il> Date: Thu, 31 Aug 2006 19:48:00 -0000 From: Michael Veksler User-Agent: Thunderbird 1.5.0.5 (X11/20060726) MIME-Version: 1.0 To: Frederic RISS , gdb@sourceware.org Subject: Re: Get versioned minsyms from dynamic symtab (Was: Re: How to call operator<< functions?) References: <44F5645F.4000301@tx.technion.ac.il> <1156936373.3429.250.camel@crx549.cro.st.com> <1156944608.3429.275.camel@crx549.cro.st.com> <1157024034.3429.303.camel@crx549.cro.st.com> <44F6D16B.7090001@tx.technion.ac.il> <1157027172.3429.309.camel@crx549.cro.st.com> <44F6DDF8.9000703@tx.technion.ac.il> <1157030582.3429.316.camel@crx549.cro.st.com> <1157042884.3429.344.camel@crx549.cro.st.com> <20060831165738.GA6529@nevyn.them.org> In-Reply-To: <20060831165738.GA6529@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00285.txt.bz2 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; > 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