I am working on Linux environment. I have two 'C' source packages train and test_train.
- train package when compiled generates libtrain.so
- 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 ?
I'm loading my library from Python and didn't have any luck with
sprof
. Instead, I usedoprofile
, which was in the Fedora repositories, at least: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.
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 usingtruss
. 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.gprof
won't work, you need to usesprof
instead. I found these links helpful:Summary from the 2nd link:
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.