GCC/GProf - 以编程方式访问线程的当前函数/堆栈跟踪

Posted 2023-03-06

【中文标题】GCC/GProf - 以编程方式访问线程的当前函数/堆栈跟踪

【英文标题】：GCC/GProf - get programmatic access to current function/stacktrace of a thread

【发布时间】：2014-04-19 09:42:55

【问题描述】：

我正在尝试做一个小时间分析。

GCC 在使用-pg 编译时添加了某些运行时检测代码（例如，用于 GProf）。

我假设它在将信息写入 gmon.out 之前将该信息存储在某个全局或线程本地数据结构中？

是否可以从代码本身的另一个线程中读取该信息（堆栈跟踪）？ （如果是这样，那么我可以添加我的挂墙时间分析线程，而无需自己添加仪器。）

【问题讨论】：

print call stack in C or C++的可能重复

【参考方案1】：

gprof 不采用堆栈跟踪，它在 CPU 时间而不是 wall 时间上工作。 它只是在 CPU 时间对程序计数器进行采样，并将其归因于它所知道的函数。 与以前的分析器相比，它的主要声名是，由于仅 PC（“自时间”）采样在调用堆栈很深的大型应用程序中非常无用， 它还计算任何函数 A 调用任何函数 B 的次数。 然后它会尝试猜测（通过一些非常不稳定的数学）可以将多少 CPU 时间计入调用低级例程的高级例程。

有一些分析器可以在墙上时间进行堆栈跟踪。 （CPU 时间意味着如果您的应用程序通过休眠、I/O-ing、挂在信号量上或其他一些阻塞以某种方式将时间消耗在非常低的水平，您将永远不会看到它。） 我知道一个在墙上时间堆叠样本的，即Zoom。 我被告知OProfile 可以做到，但我无法验证。 DTrace 也一样。

但这只是在谈论前端，即采样。

同样重要的是后端，向您展示内容的部分。 通常你会得到“热路径”、“调用图”、“火焰图”等等。

就我个人而言，我对所有这些漂亮的玩具持怀疑态度。 他们做什么，他们做得很好，毫无疑问。 但是如果 加速结果 是需要的， 那么最好的信息来自少量的堆栈样本， 在您关心的时间拍摄，实际上是查看和理解，而不仅仅是总结。

没有比程序员的脑袋更能识别模式的总结器了， 任何大到值得解决的问题都会在少量样本中显现出来。

Here's an example, 和here's another, 如果你想了解它背后的真实数学原理，look here。

【讨论】：

这都是很好的信息，但不是针对我的问题。你知道我如何使用-pg 在我自己的代码中生成的信息吗？

@eznme：您说您正在尝试进行墙上时间分析。 gprof 不做 wall-time，只做 CPU-time。您询问是否可以读取其信息（堆栈跟踪）。 gprof 不采用堆栈跟踪，仅采用 PC 样本。为了做你想做的事，除了 gprof 之外，你还需要别的东西。我试图解释一下做什么，以防万一有用。