[SOLVED] how can I get C++ heap allocated virtual method names from ltrace?

how can I get C++ heap allocated virtual method names from ltrace?

I've been struggling with this for about a day now.

I was able to construct a trivial shared library and test program, which when I run it under ltrace control I can get the method names as expected, for static, virtual and pure virtual methods.

I build my shared library using cmake. I have pure virtual parent classes, and some methods throw exceptions.

When I run ltrace on a test program, the only method name I get is from a static method.

Instead I see many lines like this:

__gxx_personality_v0(1, 2, 0x474e5543432b2b00, 0x256c800, 0x7fff8d763170)

make VERBOSE=1 shows:

...
cd /home/chchr/src/build/csp-api/platform_services_lib_dynamic && /usr/bin/c++   -Dplatform_services_EXPORTS -DVERSION=10717 -DMAJOR_PACKAGE_VERSION=0 -DMINOR_PACKAGE_VERSION=9 -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -DRMOF_BIN=\"/usr/share/rmof.bin\" -shared -g -fPIC -I/home/chchr/src/csp-api/shared/inc -I/home/chchr/src/csp-api/enclosure-lib/inc -I/home/chchr/src/csp-api/compute-lib/inc -I/home/chchr/src/csp-api/storage-lib/inc -I/home/chchr/src/csp-api/RCIM/librcimcli -I/home/chchr/src/csp-api/RCIM/libRCIM    -g -Wall -o CMakeFiles/platform_services.dir/__/shared/src/System.cpp.o -c /home/chchr/src/csp-api/shared/src/System.cpp
...
/usr/bin/c++  -fPIC  -shared -g   -shared -Wl,-soname,libplatform_services.so -o libplatform_services.so CMakeFiles/platform_services.dir/__/shared/src/System.cpp.o CMakeFiles/platform_services.dir/__/shared/src/System_Impl.cpp.o ../RCIM/librcim.so -lssl -lssh2 -lgcrypt -lslp -lcurl -lboost_system-mt -lboost_filesystem-mt -lboost_thread-mt -lpthread -Wl,-rpath,/home/chchr/src/build/csp-api/RCIM:

Any ideas where to look? Thanks!

OK, here's the deal. If an object is allocated on the heap I'm not seeing the virtual/pure virtual methods. If it's on the stack I do:

#include "foo.hpp"

int main()
{
    foo::static_foo();

    foo_child* f = new foo_child;
    f->real_foo();

    // ltrace doesn't report this one?
    f->virtual_foo();
    // ltrace doesn't report this one?
    f->pure_virtual_foo();

    foo_child g;
    g.real_foo();

    // ltrace does report this one!
    g.virtual_foo();
    // ltrace does report this one!
    g.pure_virtual_foo();

    return 0;
}



$ ltrace -C ./f
(0, 0, 0x23c300, -1, 0x1f25bc2)                                                                       = 0x3715a21160
__libc_start_main(0x4008e4, 1, 0x7fff1d54aa68, 0x400a40, 0x400a30 <unfinished ...>
foo::static_foo()(1, 0x7fff1d54aa68, 0x7fff1d54aa78, 4, 0x3715f8b300)                                 = 0x3715f8cf60
operator new(unsigned long)(8, 0x7fff1d54aa68, 0x7fff1d54aa78, 4, 0x3715f8b300)                       = 0xfc4010
foo::real_foo()(0xfc4010, 0xfc4020, 33, 0, 135168)                                                    = 0xfc4010
foo::real_foo()(0x7fff1d54a960, 0xfc4020, 0x7fc684611a86, 0, 135168)                                  = 0x7fff1d54a960
foo::virtual_foo()(0x7fff1d54a960, 0xfc4020, 0x7fc684611a86, 0, 135168)                               = 0x7fff1d54a960
foo_child::pure_virtual_foo()(0x7fff1d54a960, 0xfc4020, 0x7fc684611a86, 0, 135168)                    = 0x7fff1d54a960
+++ exited (status 0) +++

Any clue?

Solution