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?
This is a bug in ltrace. Duly reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669416