在Linux上，进程'（主线程）的最后一个程序计数器值显示在/proc/$PID/stat中。这似乎是一种非常简单易行的方法，可以进行一些采样分析，而无需以任何方式检测程序。
我想知道在采样质量方面是否有任何警告。我假设只要进程耗尽其时间片就会更新此值，应该在程序代码中以完全随机的间隔发生，并且在超过时间片长度时采集的样本应该是统一的根据程序实际花费时间的位置随机分布。但这只是一个假设，我意识到它可能在许多方面都是错误的。
有人知道吗？
答案 0 :(得分：1)
为什么不尝试像perf（https://perf.wiki.kernel.org/index.php/Main_Page）这样的现代内置Linux工具？
它具有record模式，频率可调（-F100为100 Hz），有许多事件，例如，软件事件task-clock，而不使用硬件性能计数器（停止{使用Ctrl-C {1}}或向右添加perf进行采样10秒钟）：
sleep 10 Perf适用于所有线程而无需任何检测（重新编译或代码编辑），并且不会干扰程序执行（仅略微修改定时器中断）。 （还有一些支持带有 perf record -p $PID -e task-clock -o perf.output.file
选项的堆栈跟踪采样。）
可以使用-g离线解析输出（只有此命令会尝试解析二进制和共享库）
perf report或使用 perf report -i perf.output.file
转换为原始PC（EIP）样本。
PS：/ proc / $ pid / stat文件中的EIP指针在官方linux手册第5页proc http://man7.org/linux/man-pages/man5/proc.5.html中被提及为perf script -i perf.output.file - ＆＃34;当前的EIP（指令指针）。 ＃34;它在fs/proc/array.c:do_task_stat kstkeip处阅读，但我不确定它在何时何地填充。它可以写在任务切换上（当任务结束时非自愿，当任务执行类似eip = KSTK_EIP(task);时自愿）或阻塞系统调用时，因此它可能不是作为采样源的最佳选择。
答案 1 :(得分：-1)
如果它有效，它可能会有 prof 的缺点， gprof 应该补救。然后 gprof 有自己的shortcomings，这导致了许多更现代的分析器。我们中的一些人认为this是最有效的，可以使用像 pstack 或 lsstack 这样简单的工具来完成。