Re: [PATCH v5 2/3] perf report: Support interactive annotation of code without symbols

["Jin, Yao" <yao.jin@linux.intel.com>]

On 3/18/2020 11:43 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 18, 2020 at 12:42:06PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Feb 27, 2020 at 12:39:38PM +0800, Jin Yao escreveu:
>>> For perf report on stripped binaries it is currently impossible to do
>>> annotation. The annotation state is all tied to symbols, but there are
>>> either no symbols, or symbols are not covering all the code.
>>>
>>> We should support the annotation functionality even without symbols.
>>>
>>> This patch fakes a symbol and the symbol name is the string of address.
>>> After that, we just follow current annotation working flow.
>>>
>>> For example,
>>>
>>> 1. perf report
>>>
>>> Overhead  Command  Shared Object     Symbol
>>>    20.67%  div      libc-2.27.so      [.] __random_r
>>>    17.29%  div      libc-2.27.so      [.] __random
>>>    10.59%  div      div               [.] 0x0000000000000628
>>>     9.25%  div      div               [.] 0x0000000000000612
>>>     6.11%  div      div               [.] 0x0000000000000645
>>>
>>> 2. Select the line of "10.59%  div      div               [.] 0x0000000000000628" and ENTER.
>>>
>>> Annotate 0x0000000000000628
>>> Zoom into div thread
>>> Zoom into div DSO (use the 'k' hotkey to zoom directly into the kernel)
>>> Browse map details
>>> Run scripts for samples of symbol [0x0000000000000628]
>>> Run scripts for all samples
>>> Switch to another data file in PWD
>>> Exit
>>>
>>> 3. Select the "Annotate 0x0000000000000628" and ENTER.
>>>
>>> Percent│
>>>         │
>>>         │
>>>         │     Disassembly of section .text:
>>>         │
>>>         │     0000000000000628 <.text+0x68>:
>>>         │       divsd %xmm4,%xmm0
>>>         │       divsd %xmm3,%xmm1
>>>         │       movsd (%rsp),%xmm2
>>>         │       addsd %xmm1,%xmm0
>>>         │       addsd %xmm2,%xmm0
>>>         │       movsd %xmm0,(%rsp)
>>>
>>> Now we can see the dump of object starting from 0x628.
>>
>> Testing this I noticed this discrepancy when using 'o' in the annotate
>> view to see the address columns:
>>
>> Samples: 10K of event 'cycles', 4000 Hz, Event count (approx.): 7738221585
>> 0x0000000000ea8b97  /usr/libexec/gcc/x86_64-redhat-linux/9/cc1 [Percent: local period]
>> Percent│                                                                                                                                                                                                                                                  ▒
>>         │                                                                                                                                                                                                                                                  ▒
>>         │                                                                                                                                                                                                                                                  ▒
>>         │        Disassembly of section .text:                                                                                                                                                                                                             ▒
>>         │                                                                                                                                                                                                                                                  ◆
>>         │        00000000012a8b97 <linemap_get_expansion_line@@Base+0x227>:                                                                                                                                                                                ▒
>>         │12a8b97:   cmp     %rax,(%rdi)                                                                                                                                                                                                                    ▒
>>         │12a8b9a: ↓ je      12a8ba0 <linemap_get_expansion_line@@Base+0x230>                                                                                                                                                                               ▒
>>         │12a8b9c:   xor     %eax,%eax                                                                                                                                                                                                                      ▒
>>         │12a8b9e: ← retq                                                                                                                                                                                                                                   ▒
>>         │12a8b9f:   nop                                                                                                                                                                                                                                    ▒
>>         │12a8ba0:   mov     0x8(%rsi),%edx
>>
>>
>>
>>   See that 0x0000000000ea8b97 != 12a8b97
>>
>> How can we explain that?
> 
> On another machine, in 'perf top', its ok, the same address appears on
> the second line and in the first line in the disassembled code.
> 
> I'm applying the patch,
> 
> - Arnaldo
> 

Yes, it looks strange. On my test machines, perf report and perf top 
both work fine. I'm using ubuntu 18.04.

Thanks
Jin Yao