I am working on Linux environment. I have two \'C\' source packages train and test_train.
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.
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.
gprof
won't work, you need to use sprof
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.