From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19180 invoked by alias); 31 Aug 2006 16:48:20 -0000 Received: (qmail 19171 invoked by uid 22791); 31 Aug 2006 16:48:20 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-04.spheriq.net (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Aug 2006 16:48:12 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-04.spheriq.net with ESMTP id k7VGmAOD013617 for ; Thu, 31 Aug 2006 16:48:10 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-03.spheriq.net with ESMTP id k7VGm6xM021297 for ; Thu, 31 Aug 2006 16:48:06 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id k7VGm61I007659 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Aug 2006 16:48:06 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B6E1EDA41; Thu, 31 Aug 2006 16:48:05 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 78F2E474FD; Thu, 31 Aug 2006 16:48:05 +0000 (GMT) Received: from crx549.cro.st.com (crx549.cro.st.com [164.129.44.49]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CII21621 (AUTH "frederic riss"); Thu, 31 Aug 2006 18:48:04 +0200 (CEST) Subject: Re: Get versioned minsyms from dynamic symtab (Was: Re: How to call operator<< functions?) From: Frederic RISS To: Michael Veksler Cc: gdb@sourceware.org In-Reply-To: <1157030582.3429.316.camel@crx549.cro.st.com> 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> Content-Type: text/plain Date: Thu, 31 Aug 2006 16:48:00 -0000 Message-Id: <1157042884.3429.344.camel@crx549.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00280.txt.bz2 On Thu, 2006-08-31 at 15:23 +0200, Frederic RISS wrote: > On Thu, 2006-08-31 at 16:02 +0300, Michael Veksler wrote: > > Take the two files from my test case in: > > http://sources.redhat.com/ml/gdb/2006-08/msg00271.html > > [...] > > (gdb) p x.Print(std::cout) > > Enter B::Print() this=0xbfffec00 > > $1 = void > > (gdb) p x.Print(myCout) > > Cannot resolve method B::Print to any overloaded instance > > (gdb) p x.Print(std::cout) > > Cannot resolve method B::Print to any overloaded instance > > (gdb) > > ============== > > What is going on here. Why the second Print(std::cout) no longer works? > > Let's try to rerun without exiting GDB: > > Sorry, I can't reproduce that... this is working fine here. In fact I managed to reproduce this behavour using a libstdc++ compiled without debug information. What's happening is quite strange, and it might very well be a GCC bug and not a GDB one. 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 > 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. 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... I thought that using -feliminate-dwarf2-dups would help, but it doesn't. One thing we could do is to compare the TYPE_TAG_NAME for overload resoltion if there's no type name. During my tests, it was set to 'std::basic_ostream >' but I've read some comments stating that it shouldn't be used. Or maybe the bug is that we don't fill TYPE_NAME with that information?