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

[Arnaldo Carvalho de Melo]

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@xxxxxxxxxx> 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@xxxxxxxxxx>

-- 

- Arnaldo