Re: How to call operator<< functions?

[Frederic RISS <frederic.riss@st.com>]

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.