| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 19 Mar 2020 08:56:16 +0800
From: "Jin, Yao" <yao.jin@...ux.intel.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc: jolsa@...nel.org, peterz@...radead.org, mingo@...hat.com,
alexander.shishkin@...ux.intel.com, Linux-kernel@...r.kernel.org,
ak@...ux.intel.com, kan.liang@...el.com, yao.jin@...el.com
Subject: Re: [PATCH v5 2/3] perf report: Support interactive annotation of
code without symbols
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
Powered by blists - more mailing lists