How can I get perf to find symbols in my program

后端 未结 8 1602
醉梦人生
醉梦人生 2021-01-30 09:24

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

$ perf record /path/to/racket ints.rkt 10000
$ pe         


        
相关标签:
8条回答
  • 2021-01-30 09:47

    You can always use the '$ nm ' command.

    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
    
    0 讨论(0)
  • 2021-01-30 09:47

    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

    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.

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

    my final command was

    perf record -F 999 -g ./my_program

    didn't need --call-graph

    0 讨论(0)
  • 2021-01-30 09:51

    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 question very helpful. On my Ubuntu Raring system, I then ended up doing the following:

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

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

      This way perf is able to handle the DWARF 2 debug format, which is the standard format gcc uses on Linux. The -F 97 parameter 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 report call afterwards would fail with a segmentation fault. With the reduced sampling rate everything worked out fine.

    3. Once the perf.data file has been generated without any errors in the previous step, you can run perf report etc. I personally like the FlameGraph tools to generate SVG visualizations.
    4. Other people reported that running

      echo 0 > /proc/sys/kernel/kptr_restrict
      

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

    0 讨论(0)
  • 2021-01-30 09:51

    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.

    $objdump -t your-elf 
    $readelf -a your-elf
    $nm -a your-elf
    
    0 讨论(0)
  • 2021-01-30 10:00

    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.

    0 讨论(0)
  • 2021-01-30 10:01

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

    As I can see your case is pretty similar:

    70.06% ints.rkt [unknown]

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

    0 讨论(0)
提交回复
热议问题