2

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?

  • I created a Makefile to do the same thing and got the same unexpected results: `all: libpl.so simple libpl.so: g++ -Wl,--export-dynamic -fPIC -shared -o libpl.so \ -rdynamic \ -O0 -g \ -I../shared/inc \ -I../storage-lib/inc \ -I../compute-lib/inc \ -I../enclosure-lib/inc \ -I../RCIM/libRCIM \ -I../RCIM/librcimcli \ ../shared/src/System.cpp` – Chip Christian Apr 19 '12 at 01:00
  • Functions with names that start with __gxx or __cxa belong to C++ runtime, not to your program. Don't worry about them. Filter them out and you should see just your functions. – n. m. could be an AI Apr 19 '12 at 14:55

2 Answers2

1

add "-C" option with ltrace to support tracing C++ method names

the man page discription of ltrace "-C" option is:

-C, --demangle Decode (demangle) low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes C++ function names readable.

ltrace -C program

Output should like this:

*std::basic_string, std::allocator >::basic_string(std::string const&)(0x8fb940, 0x7fff6fc680b0, 0x7fff6fc680b0, 0x50535f4444415f46, 0x4c4941465f455241) = 0x1970be8*

While sometimes it's still a bit hard to understand, enjoy ^_^

Uranus
  • 11
  • 1
  • Sorry, I'm not being clear enough... I've done that. The issue is that not all of my methods are showing in the output and for the life of me I cannot figure out what's wrong. I'm trying to reduce it to a small example that doesn't work to post. – Chip Christian Apr 19 '12 at 14:39
1

This is a bug in ltrace. Duly reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669416