gprof : How to generate call graph for functions in shared library that is linked to main program

30
votes

I am working on Linux environment. I have two 'C' source packages train and test_train.

  1. train package when compiled generates libtrain.so
  2. test_train links to libtrain.so and generates executable train-test

Now I want to generate a call graph using gprof which shows calling sequence of functions in main program as well as those inside libtrain.so

I am compiling and linking both packages with -pg option and debugging level is o0. After I do ./train-test , gmon.out is generated. Then I do:

$ gprof -q ./train-test gmon.out

Here, output shows call graph of functions in train-test but not in libtrain.so

What could be the problem ?

3
cdebuggingprofilinggprofsprof

3 Answers

24
votes

gprof won't work, you need to use sprof instead. I found these links helpful:

Summary from the 2nd link:

  1. Compile your shared library (libmylib.so) in debug (-g) mode. No -pg.
  2. export LD_PROFILE_OUTPUT=`pwd`
  3. export LD_PROFILE=libmylib.so
  4. rm -f $LD_PROFILE.profile
  5. execute your program that loads libmylib.so
  6. sprof PATH-TO-LIB/$LD_PROFILE $LD_PROFILE.profile -p >log
  7. See the log.

I found that in step 2, it needs to be an existing directory -- otherwise you get a helpful warning. And in step 3, you might need to specify the library as libmylib.so.X (maybe even .X.Y, not sure) -- otherwise you get no warning whatsoever.

3
votes

I'm loading my library from Python and didn't have any luck with sprof. Instead, I used oprofile, which was in the Fedora repositories, at least:

operf --callgraph /path/to/mybinary

Wait for your application to finish or do Ctl-c to stop profiling. Now let's generate a profile summary:

opreport --callgraph --symbols

See the documentation to interpret it. It's kind of a mess. In the generated report, each symbol is listed in a block of its own. The block's main symbol is the one that's not indented. The items above it are functions that call that function, and the ones below it are the things that get called by it. The percentages in the below section are the relative amount of time it spent in those callees.

1
votes

If you're not on Linux (like me on Solaris) you simply out of luck as there is no sprof there. If you have the sources of your library you can solve your problem by linking a static library and making your profiling binary with that one instead. Another way I manage to trace calls to shared libraries, is by using truss. With the option -u [!]lib,...:[:][!]func, ... one can get a good picture of the call history of a run. It's not completely the same as profiling but can be very usefull in some scenarios.