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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <400348ef-14d2-e27c-d073-2b2fb42837f2@linux.intel.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ