From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13713 invoked by alias); 30 Aug 2006 13:30:26 -0000 Received: (qmail 13705 invoked by uid 22791); 30 Aug 2006 13:30:26 -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; Wed, 30 Aug 2006 13:30:21 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-04.spheriq.net with ESMTP id k7UDUDP9022387 for ; Wed, 30 Aug 2006 13:30:13 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-01.spheriq.net with ESMTP id k7UDUD16009587 for ; Wed, 30 Aug 2006 13:30:13 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 k7UDUAD9013371 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 30 Aug 2006 13:30:12 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 49AF4DA49 for ; Wed, 30 Aug 2006 13:30:10 +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 0C2D147546 for ; Wed, 30 Aug 2006 13:30:09 +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 CIH93004 (AUTH "frederic riss"); Wed, 30 Aug 2006 15:30:08 +0200 (CEST) Subject: Re: How to call operator<< functions? From: Frederic RISS To: gdb@sourceware.org In-Reply-To: <1156936373.3429.250.camel@crx549.cro.st.com> References: <44F5645F.4000301@tx.technion.ac.il> <1156936373.3429.250.camel@crx549.cro.st.com> Content-Type: text/plain Date: Wed, 30 Aug 2006 13:30:00 -0000 Message-Id: <1156944608.3429.275.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/msg00244.txt.bz2 On Wed, 2006-08-30 at 13:12 +0200, Frederic RISS wrote: > I've already encountered the issue with cout. In my case the _ZSt4cout > symbol was present in the debugged binary and (obviously) in libstdc++. > I _think_ that GDB resolved _ZSt4cout as if the symbol in the library > was used whereas the one in the executable was the right one. I can't > remember the reasons for this right now. I digged an old testcase out. Very simple: -----------------------------8<----------------------------------- #include void dump (std::ostream& os) { os << "Hello, guys!" << std::endl; } int main () { std::cout << "&std::cout is " << &std::cout << std::endl; dump (std::cout); return 0; } -----------------------------8<----------------------------------- With neither of the toolcahins I tried (all x86, gcc 4.0 and 4.1 with recent binutils) I could get the correct value for &std::cout: rf23@crx549 ~/tmp/cout % gdb --silent a.out Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x8048703: file cout.cc, line 11. Starting program: /home/rf23/tmp/cout/a.out main () at cout.cc:11 11 std::cout << "&std::cout is " << &std::cout << std::endl; (gdb) n &std::cout is 0x8049a78 12 dump (std::cout); (gdb) p &std::cout $1 = (ostream *) 0x582b40 p dump (std::cout) Program received signal SIGSEGV, Segmentation fault. As you can see, we get the wrong address. Thus we fail to pass the right object when calling a function. Little (re-)investigation showed that this is related to symbol versionning. In the static symtab the std::cout symbol is versioned and is recorded as such in GDB's minsym table: rf23@crx549 ~/tmp/cout % nm a.out| grep cout 49:08049a78 B _ZSt4cout@@GLIBCXX_3.4 rf23@crx549 ~/tmp/cout % nm -D a.out| grep cout 11:08049a78 B _ZSt4cout This can be confirmed from within GDB: (gdb) p &'_ZSt4cout@@GLIBCXX_3.4' $2 = ( *) 0x8049a78 I don't know how we should handle that. Trimming the symbol versions seems wrong (and scanning each symbol for @@ has a cost). Maybe we shouldn't skip the dynamic symtab for the main executable? Not sure if it'll solve all such cases. Fred.