Re: [PATCH v2 1/4] perf probe: Generate event name with line number

[Masami Hiramatsu <mhiramat@kernel.org>]

On Wed, 13 Nov 2019 09:09:27 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Wed, Nov 13, 2019 at 08:01:57AM +0700, Masami Hiramatsu escreveu:
> > Hi Arnaldo,
> > 
> > On Tue, 12 Nov 2019 17:31:31 +0700
> > Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > > > > # perf probe --list
> > > > > >   probe:kernel_read_l1 (on kernel_read@fs/read_write.c)
> > > > > >   probe:kernel_read_l2 (on kernel_read:1@fs/read_write.c)
> > > > > 
> > > > > 
> > > > > Also look above at the listing, I would expect this instead:
> > > > > 
> > > > > # perf probe --list
> > > > >   probe:kernel_read_l1 (on kernel_read:1@fs/read_write.c)
> > > > >   probe:kernel_read_l2 (on kernel_read:2@fs/read_write.c)
> > > > > 
> > > > > Right?
> > > 
> > > Yes, it should be so.
> > 
> > Hmm, this looks the limiation of debuginfo generated by gcc.
> > Let me explain what happens. So, here is the decoded Line info in
> > debuginfo for kernel_read (is defined in fs/read_write.c:423)
> > 
> > ---
> > $ readelf -wL /usr/lib/debug/boot/vmlinux-5.0.0-32-generic 
> > ...
> > read_write.c                                 444  0xffffffff812b435d        
>                                                ^^^
> 					       424, right?

No, the line info is sorted by address. This seems strange, but happens sometimes :)

> > read_write.c                                 424  0xffffffff812b4370               x
> > read_write.c                                 425  0xffffffff812b4375               x
> > read_write.c                                 426  0xffffffff812b4375       1       x
> > read_write.c                                 428  0xffffffff812b4375       2       x
> > 
> > ---
> > This shows the line number info points the kernel_read entry address is
> > on #424, this means we can not distinguish kernel_read:0 and kernel_read:1
> > from only the address information.cw
> 
> If both 0xffffffff812b435d and 0xffffffff812b4370 are associated with
> line 424, then we should present on 'perf probe -L' just the first one
> and do the same when converting from address to name when presenting
> with 'perf probe -l'?

OK, so we can pick only one of them (the first "statement" line among
several lines which shares same address), and show only that line can
be probed by perf probe -L.

> 
> > (maybe huristically we can distinguish it by the "_L1" suffix. But if
> > user gives another event name, it doesn't work.)
> 
> > ---
> > 
> > /build/linux-pvZVvI/linux-5.0.0/arch/x86/include/asm/current.h:
> > current.h                                     13  0xffffffff812b4375       3       x
> > current.h                                     15  0xffffffff812b4375       4       x
> > current.h                                     15  0xffffffff812b4375       5       x
> > current.h                                     15  0xffffffff812b4375       6       x
> > current.h                                     15  0xffffffff812b4375       7       x
> > 
> > /build/linux-pvZVvI/linux-5.0.0/fs/read_write.c:
> > read_write.c                                 424  0xffffffff812b4375       8
> > 
> > ---
> > And it seems that the dwarf_getsrc_die() returns the last line info
> > correspoinding to given address (0xffffffff812b4375) even if it is
> > not a stetement line. This is why probe:kernel_read_l2 is 
> > on kernel_read:1. I will fix that.
> 
> by going backwards from what dwarf_getsrc_die() returns till it finds a
> statement line?

Moreover, going backward and forward until it finds the smallest line
number which is a statement. Because it uses a binary search, it can
find non-statement lines.

>  
> > However, again, as long as the different lines are encoded in same
> 
> It is possible as well to have different addresses associated with the
> same source code line.

That is OK, since we now support multiprobes. We can put probes on
different addresses on same line (but different column).

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>