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

[Jin, Yao]

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