Re: Fedora 33 and perf probe failures

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Thu, Nov 26, 2020 at 10:08:48PM +0900, Masami Hiramatsu escreveu:
> Hi Thomas,
> 
> I've setup fedora33 and found strange debuginfo.
> 
> On Thu, 19 Nov 2020 09:16:57 +0100
> Thomas Richter <tmricht@linux.ibm.com> wrote:
> 
> > [root@f33 ~]# perf probe -vvv -L getname_flags
> > Looking at the vmlinux_path (8 entries long)
> > Using /lib/modules/5.9.8-200.fc33.x86_64/build/vmlinux for symbols
> > Open Debuginfo file: /lib/modules/5.9.8-200.fc33.x86_64/build/vmlinux
> > fname: ./include/linux/fs.h, lineno:2527
> > New line range: 2527 to 2147483647
> > path: (null)
> > Specified source line is not found.
> >   Error: Failed to show lines. Reason: No such file or directory (Code: -2)
> 
> Above error was reproduced, and I found that the perf-probe's routine
> failed to find the real function definition.
> 
> I decoded the vmlinux with eu-readelf -w, and I found there were 2
> entries (DIEs) for the getname_flags.
> 
> (1)
>  [2dbe7c6]    subprogram           abbrev: 54
>              external             (flag_present) yes
>              name                 (strp) "getname_flags"
>              decl_file            (data1) fs.h (8)
>              decl_line            (data2) 2527
>              decl_column          (data1) 25
>              prototyped           (flag_present) yes
>              type                 (ref4) [2dbe7e7]
>              sibling              (ref4) [2dbe7e7]
>  [2dbe7d7]      formal_parameter     abbrev: 4
>                type                 (ref4) [2da9721]
>  [2dbe7dc]      formal_parameter     abbrev: 4
>                type                 (ref4) [2da97a1]
>  [2dbe7e1]      formal_parameter     abbrev: 4
>                type                 (ref4) [2dabbdd]
> 
> (2)
>  [2e0fde0]    subprogram           abbrev: 162
>              external             (flag_present) yes
>              name                 (strp) "getname_flags"
>              decl_file            (data1) namei.c (1)
>              decl_line            (data1) 128
>              decl_column          (data1) 1
>              prototyped           (flag_present) yes
>              type                 (ref4) [2dfced6]
>              inline               (data1) inlined (1)
>              sibling              (ref4) [2e0fe49]
>  [2e0fdf2]      formal_parameter     abbrev: 31
>                name                 (strp) "filename"
>                decl_file            (data1) namei.c (1)
>                decl_line            (data1) 128
>                decl_column          (data1) 34
>                type                 (ref4) [2de77f3]
>  [2e0fdfe]      formal_parameter     abbrev: 31
>                name                 (strp) "flags"
>                decl_file            (data1) namei.c (1)
>                decl_line            (data1) 128
>                decl_column          (data1) 48
>                type                 (ref4) [2de7873]
>  [2e0fe0a]      formal_parameter     abbrev: 31
>                name                 (strp) "empty"
>                decl_file            (data1) namei.c (1)
>                decl_line            (data1) 128
>                decl_column          (data1) 60
>                type                 (ref4) [2de9ce4]
> 
> The first one is not the actual function, but that is a DIE
> for the declaration. However, this DIE doesn't have DW_AT_declaration
> attribute, it should be there if the DIE represents the declaration.

Its a bug in some gdb versions, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060

And here is the pahole cset dealing with that:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=5a22c2de79fb9edf2d36ff4e8d440a862fc99c2a
 
> In perf, die_is_func_def() checks that attribute, and if the DIE doen't
> have DW_AT_declaration, line_range_search_cb() think the DIE represents
> the function definition (function prototype). And search the instance
> to find the line range.
> 
> However, since the (1) has no DW_AT_declaration, perf probe was mislead
> that the DIE is the function definition, and search the function instance
> which links to the DIE. And it failed to find any instances because
> the DIE it found was just a prototype in the header file. (But it seems
> some call-site DIE refers the declaration DIE.)
> 
> Let me try to fix if we skip the first DIE.
> 
> Thank you,
> 
> -- 
> Masami Hiramatsu <mhiramat@kernel.org>

-- 

- Arnaldo