gprof：如何为链接到主程序的共享库中的函数生成调用图
我正在Linux环境下工作。我有两个“C”源代码包 train 和 test_train。
- train 包编译时会生成 libtrain.so
- test_train 链接到 libtrain.so 并生成可执行的 train-test
现在我想使用 gprof 生成一个调用图，它显示主程序中的函数调用顺序以及
我正在编译的 libtrain.so 中的函数调用顺序并使用 -pg 选项链接这两个包，调试级别为 o0。 在我执行 ./train-test 后，生成 gmon.out 。然后我这样做：
$ gprof -q ./train-test gmon.out
这里，输出显示了 train-test 中函数的调用图，但不在 libtrain.so 中，
这可能是什么问题？
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
gprof不起作用，您需要使用sprof代替。我发现这些链接很有帮助：第二个链接的摘要：
我发现在第 2 步中，它必须是一个现有目录——否则您会收到有用的警告。在第 3 步中，您可能需要将库指定为
libmylib.so.X（甚至可能是.XY，不确定）——否则您不会收到任何警告。gprofwon't work, you need to usesprofinstead. 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.我正在从 Python 加载我的库，但
sprof没有任何运气。相反，我使用了oprofile，它至少位于 Fedora 存储库中：请参阅 文档来解释它。有点乱。在生成的报告中，每个符号都列在其自己的块中。该块的主要符号是未缩进的符号。它上面的项目是调用该函数的函数，下面的项目是被该函数调用的东西。下面部分中的百分比是它在这些被调用者中花费的相对时间量。
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.
如果您不在 Linux 上（就像我在 Solaris 上一样），那您就运气不好了，因为那里没有
sprof。如果您有库的源代码，您可以通过链接静态库并使用该静态库制作分析二进制文件来解决您的问题。
我设法跟踪对共享库的调用的另一种方法是使用 truss。使用选项
-u [!]lib,...:[:][!]func, ...可以很好地了解一次运行的调用历史记录。它与分析并不完全相同，但在某些情况下非常有用。If you're not on Linux (like me on Solaris) you simply out of luck as there is no
sprofthere.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.