lkml.org 
[lkml]   [2020]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 2/3] perf report: Support interactive annotation of code without symbols
From
Date


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

\
 
 \ /
  Last update: 2020-03-19 01:57    [W:0.126 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site