Hi,
I noticed a small anomaly in perf report -v output on ARC and x86 as well.
A simple program which sits in tight loop, compiled for x86_64
void main() { while(1) {} }
$ gcc -g tight.c
$ ./a.out &
$ perf record -e cycles -p 26703
$ perf report -n -v --stdio | egrep "(main|Symbol)"
|# Overhead Samples Command Shared Object Symbol
| 99.93% 55753 a.out /home/arc/test/a.out 0x4da B [.] main
| ^^^^^
The printer address for Symbols is *not* the actual address in elf, but rather VMA
start offset.
0x4da = 0x4004da - 0x0000000000400000
$ objdump -d ./a.out
| 00000000004004d6 <main>:
| 4004d6: 55 push %rbp
| 4004d7: 48 89 e5 mov %rsp,%rbp
| 4004da: eb fe jmp 4004da <main+0x4>
| 4004dc: 0f 1f 40 00 nopl 0x0(%rax)
$ readelf -a ./a.out
| Program Headers:
| Type Offset VirtAddr PhysAddr
| FileSiz MemSiz Flags Align
| Program Headers:
| LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000000068c 0x000000000000068c R E 200000
This is problematic in narrowing down the hotspot instruction, when the binary
itself is. One needs to do the offset addition manually to find the actual hotspot
location.
| 99.79% 100064 a.out /home/arc/test/a.out 0x4da B [.] 0x00000000000004da
^^^^^^^^^^^^^^^^
Is this considered an issue ? Would the fix to print the actual symbol address
(and recorded in raw perf event data) break some existing tooling etc.
-Vineet
