Profiling a preloaded shared library with LD_PROFILE

Question

I'm currently trying to profile a preloaded shared library by using the LD_PROFILE environment variable.

I compile the library with "-g" flag and export LD_PROFILE_OUTPUT as well as LD_PROFILE before running an application (ncat in my case) with the preloaded library. So, more precisely what I do is the following:

1. Compile shared library libexample.so with "-g" flag.
2. export LD_PROFILE_OUTPUT=`pwd`
3. export LD_PROFILE=libexample.so
4. run LD_PRELOAD=`pwd`/libexample.so ncat ...

The preloading itself does work and my library is used, but no file libexample.so.profile gets created. If I use export LD_PROFILE=libc.so.6 instead, there is a file libc.so.6.profile as expected.

Is this a problem of combining LD_PRELOAD and LD_PROFILE or is there anything I might have done wrong?

I'm using glibc v2.12 on CentOS 6.4 if that is of any relevance.

Thanks a lot!

Answer 1

Sorry, I don't know the answer why LD_PROFILE does not work with LD_PRELOAD.

However, for profiling binaries compiled with -g I really like the tool valgrind together with the grapichal tool kcachegrind.

valgrind --tool=callgrind /path/to/some/binary with options

will create a file called something like callgrind.out.1234 where 1234 was the pid of the program when run. That file can be analyzed with:

kcachegrind callgrind.out.1234

In kcachegrind you will easily see in which functions most CPU time is spended, the callee map also shows this in a nise graphical way. The call graph might help to understand how the program works. You will even be able to look at the source code to see how much CPU time is spent on each line.

I hope that you will find valgrind useful even though this was not the answer to your LD_PROFILE question. The drawback of valgrind is that it slows things down both when valgrind is used for profiling and memory checking.