This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to call operator<< functions?
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 <iostream>
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 = (<data variable, no debug info> *) 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.