Linux 如何获得 perf 以在我的程序中查找符号

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/10933408/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-06 06:42:05  来源:igfitidea点击:

How can I get perf to find symbols in my program

linuxperformanceperf

提问by Sam Tobin-Hochstadt

When using perf report, I don't see any symbols for my program, instead I get output like this:

使用时perf report,我没有看到我的程序的任何符号,而是得到如下输出:

$ perf record /path/to/racket ints.rkt 10000
$ perf report --stdio

# Overhead   Command      Shared Object  Symbol
# ........  ........  .................  ......
#
    70.06%  ints.rkt  [unknown]          [.] 0x5f99b8        
    26.28%  ints.rkt  [kernel.kallsyms]  [k] 0xffffffff8103d0ca
     3.66%  ints.rkt  perf-32046.map     [.] 0x7f1d9be46650  

Which is fairly uninformative.

这是相当缺乏信息的。

The relevant program is built with debugging symbols, and the sysproftool shows the appropriate symbols, as does Zoom, which I think is using perfunder the hood.

相关程序是用调试符号构建的,该sysprof工具显示了适当的符号,我认为 Zoom 也是如此,我认为它是perf在幕后使用的。

Note that this is on x86-64, so the binary is compiled with -fomit-frame-pointer, but that's the case when running under the other tools as well.

请注意,这是在 x86-64 上,因此二进制文件是使用 编译的-fomit-frame-pointer,但在其他工具下运行时也是如此。

回答by jumper

How about your dev host machine? Is it also running the x86_64 OS? If not, please make sure the perf is cross-compiled, because the perf depends on the objdump and other tools in toolchain.

你的开发主机怎么样?它还运行 x86_64 操作系统吗?如果没有,请确保 perf 是交叉编译的,因为 perf 依赖于 objdump 和工具链中的其他工具。

回答by phyrrus9

You can always use the '$ nm ' command.

您始终可以使用 '$ nm ' 命令。

here is some sample output:

这是一些示例输出:

Ethans-MacBook-Pro:~ phyrrus9$ nm a.out
0000000100000000 T __mh_execute_header
0000000100000f30 T _main
                 U _printf
0000000100000f00 T _sigint
                 U _signal
                 U dyld_stub_binder

回答by New to Rails

Make sure that you compile the program using -g option along with gcc(cc) so that debugging information is produced in the operating system's native format. Try to do the following and check if there are debug symbols present in the symbol table.

确保使用 -g 选项和 gcc(cc) 编译程序,以便以操作系统的本机格式生成调试信息。尝试执行以下操作并检查符号表中是否存在调试符号。

$objdump -t your-elf 
$readelf -a your-elf
$nm -a your-elf

回答by Nik_

I got the same problem with perfafter overriding the name of my program via prctl(PR_SET_NAME)

通过覆盖我的程序名称后,我遇到了与perf相同的问题prctl(PR_SET_NAME)

As I can see your case is pretty similar:

正如我所看到的,您的情况非常相似:

70.06% ints.rkt[unknown]

70.06% ints.rkt[未知]

Command you have executed (racket) is different from the one perfhave seen.

您执行的命令 ( racket) 与perf看到的命令不同。

回答by yzark

you can check the value of kptr_restrict by cat /proc/kallsyms. If the addresses of the symbols in the result are all 0x000000, you can fix it by command echo 0 > sys/kernel/kptr_restrict. After this , you may get a wanted result of the perf report

您可以通过检查 kptr_restrict 的值cat /proc/kallsyms。如果结果中符号的地址都是0x000000,可以通过命令修复echo 0 > sys/kernel/kptr_restrict。在此之后,您可能会得到想要的结果perf report

回答by mindriot

This post is already over a year old, but since it came out at the top of my Google search results when I had the same problem, I thought I'd answer it here. After some more searching around, I found the answer given in this related StackOverflow questionvery helpful. On my Ubuntu Raring system, I then ended up doing the following:

这篇文章已经有一年多了,但是当我遇到同样的问题时它出现在我的谷歌搜索结果的顶部,我想我会在这里回答。经过更多的搜索,我发现这个相关的 StackOverflow 问题中给出答案非常有帮助。在我的 Ubuntu Raring 系统上,我最终做了以下事情:

  1. Compile my C++ sources with -g(fairly obvious, you need debug symbols)
  2. Run perfas

    record -g dwarf -F 97 /path/to/my/program
    

    This way perfis able to handle the DWARF 2debug format, which is the standard format gccuses on Linux. The -F 97parameter reduces the sampling rate to 97 Hz. The default sampling rate was apparently too large for my system and resulted in messages like this:

    Warning:
    Processed 172390 events and lost 126 chunks!
    
    Check IO/CPU overload!
    

    and the perf reportcall afterwards would fail with a segmentation fault. With the reduced sampling rate everything worked out fine.

  3. Once the perf.datafile has been generated without any errors in the previous step, you can run perf reportetc. I personally like the FlameGraphtools to generate SVG visualizations.
  4. Other peoplereported that running

    echo 0 > /proc/sys/kernel/kptr_restrict
    

    as root can help as well, if kernel symbols are required.

  1. 编译我的 C++ 源代码-g(很明显,你需要调试符号)
  2. 运行perf方式

    record -g dwarf -F 97 /path/to/my/program
    

    这种方式perf能够处理DWARF 2调试格式,这是gccLinux 上使用的标准格式。该-F 97参数将采样率降低到 97 Hz。默认采样率显然对我的系统来说太大了,并导致了这样的消息:

    Warning:
    Processed 172390 events and lost 126 chunks!
    
    Check IO/CPU overload!
    

    perf report之后的调用将因分段错误而失败。随着采样率的降低,一切都很好。

  3. 一旦perf.data文件在上一步中没有任何错误地生成,您就可以运行perf report等。我个人喜欢FlameGraph工具来生成 SVG 可视化。
  4. 其他人报告说,跑步

    echo 0 > /proc/sys/kernel/kptr_restrict
    

    如果需要内核符号,作为 root 也可以提供帮助。

回答by Bill Yan

I had this problem too, I couldn't see any userspace symbol, but I saw some kernel symbols. I thought this was a symbol loading issue. After tried all the possible solutions I could find, I still couldn't get it work.

我也有这个问题,我看不到任何用户空间符号,但我看到了一些内核符号。我认为这是一个符号加载问题。在尝试了我能找到的所有可能的解决方案后,我仍然无法让它工作。

Then I faintly remember that

然后我依稀记得

ulimit -u unlimited

ulimit -u 无限制

is needed. I tried and it magically worked.

需要。我试过了,它神奇地起作用了。

I found from this wiki that this command is needed when you use too many file descriptors.

我从这个 wiki 中发现,当您使用太多文件描述符时需要此命令。

https://perf.wiki.kernel.org/index.php/Tutorial#Troubleshooting_and_Tips

https://perf.wiki.kernel.org/index.php/Tutorial#Troubleshooting_and_Tips

my final command was

我的最终命令是

perf record -F 999 -g ./my_program

性能记录 -F 999 -g ./my_program

didn't need --call-graph

不需要--call-graph

回答by sotiris

In my case the solution was to delete the elf files which contained cached symbols from previous builds and were messing things up.

在我的情况下,解决方案是删除包含先前构建中缓存符号的 elf 文件,并且将事情搞砸了。

They are in ~/.debug/ folder

它们在 ~/.debug/ 文件夹中