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

Masami Hiramatsu
2019-11-14T04:14:46Z

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>