lkml.org 
[lkml]   [2019]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 1/4] perf probe: Generate event name with line number
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?
> 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'?

> (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?

> 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.

> address, we can not distinguish them except for checking "_L*"
> suffix.
>
> Possible solutions are
> - Do not allow user to put probes on lines which shares the address
> with other lines (user can put a probe only on the earliest line)


> - Warn user that the line shares address with other lines and put
> the probe with the earliest line number suffix.
> - Just warn user.
>
> THank you,
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>

--

- Arnaldo

\
 
 \ /
  Last update: 2019-11-13 13:11    [W:0.133 / U:5.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site