Description of problem:
The kernel debuginfo contains a prototype subprogram for SyS_fadvise64_64, and an inline instance referencing that under SyS_fadvise64.  However, the debuginfo does not have a concrete subprogram (with low/high_pc), even though I can see it does exist in the symbol table and /proc/kallsyms.  The same kernel on F21 is fine.

Version-Release number of selected component (if applicable):
kernel-debuginfo-4.0.7-300.fc22.x86_64
built with gcc-5.1.1-4.fc22.x86_64 and binutils-2.25-8.fc22.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Confirm the subprogram does exist in the symbol table.
2. Find the subprogram DIE declaring "SyS_fadvise64_64"
3. Look for DIEs which reference that as DW_AT_abstract_origin

Actual results:
Only an inline instance exists, under SyS_fadvise64.

Expected results:
Should have that inline and also a standalone subprogram.

Additional info:
This was found in systemtap:
https://sourceware.org/bugzilla/show_bug.cgi?id=18701

With syscall wrappers, you get the real function named SyS_foo and an alias sys_foo.  It may be worth noting that function is only called by the aliased name, both in the same CU mm/fadvise.c, and also in arch/x86/ia32/sys_ia32.c.  The latter CU also gets a subprogram prototype for "sys_fadvise64_64".  I'm not sure this is any problem though, as f21 is the same and it works fine.

With dwgrep, it's easy to search the DIEs to see the problem.

$ nm /usr/lib/debug/lib/modules/4.0.7-300.fc22.x86_64/vmlinux \
  | grep -i sys_fadvise64
ffffffff811e3940 T sys_fadvise64
ffffffff811e3940 T SyS_fadvise64
ffffffff811e36d0 T sys_fadvise64_64
ffffffff811e36d0 T SyS_fadvise64_64
$ dwgrep 'entry ?(@AT_name == "SyS_fadvise64_64")' \
  /usr/lib/debug/lib/modules/4.0.7-300.fc22.x86_64/vmlinux
[1864fa0]       subprogram
        external        true
        name    "SyS_fadvise64_64"
        decl_file       "mm/fadvise.c"
        decl_line       28
        prototyped      true
        type    [1857399] base_type
        inline  inlined
        sibling [1864fe7] subprogram
[1865196]       inlined_subroutine
        abstract_origin [1864fa0] subprogram
        entry_pc        0xffffffff811e395f
        ranges  0xffffffff811e395f..0xffffffff811e3a25, 0xffffffff811e3a38..0xffffffff811e3a54, 0xffffffff811e3a68..0xffffffff811e3ba9
        call_file       "mm/fadvise.c"
        call_line       159

We have the inline call within SyS_fadvise64, but not its own subprogram.

Compare to F21 where it's fine:

$ nm /usr/lib/debug/lib/modules/4.0.7-200.fc21.x86_64/vmlinux \
  | grep -i sys_fadvise64
ffffffff811e2730 T sys_fadvise64
ffffffff811e2730 T SyS_fadvise64
ffffffff811e24b0 T sys_fadvise64_64
ffffffff811e24b0 T SyS_fadvise64_64
$ dwgrep 'entry ?(@AT_name == "SyS_fadvise64_64")' \
  /usr/lib/debug/lib/modules/4.0.7-200.fc21.x86_64/vmlinux
[187f75e]       subprogram
        external        true
        name    "SyS_fadvise64_64"
        decl_file       "mm/fadvise.c"
        decl_line       28
        prototyped      true
        type    [1871bea] base_type
        inline  inlined
        sibling [187f7a5] subprogram
[187f892]       subprogram
        abstract_origin [187f75e] subprogram
        low_pc  0xffffffff811e24b0
        high_pc 625
        frame_base      0..0xffffffffffffffff:0 call_frame_cfa
        GNU_all_call_sites      true
        sibling [187fcc4] subprogram
[187fd62]       inlined_subroutine
        abstract_origin [187f75e] subprogram
        entry_pc        0xffffffff811e274f
        ranges  0xffffffff811e274f..0xffffffff811e2875, 0xffffffff811e2888..0xffffffff811e28a4, 0xffffffff811e28b8..0xffffffff811e29a1
        call_file       "mm/fadvise.c"
        call_line       159

We have both the inline and its own subprogram with proper pc ranges.