| 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
| ||
|
Message-ID: <20200318154358.GH11531@kernel.org>
Date: Wed, 18 Mar 2020 12:43:58 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Jin Yao <yao.jin@...ux.intel.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
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
Powered by blists - more mailing lists