[Bug debug/103135] New: DW_AT_high_pc 0 offset for inlined functions with a singled instruction

[Bug debug/103135] New: DW_AT_high_pc 0 offset for inlined functions with a singled instruction

[wcohen at redhat dot com]

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

            Bug ID: 103135
           Summary: DW_AT_high_pc 0 offset for inlined functions with a
                    singled instruction
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

Created attachment 51749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51749&action=edit
Reproducer to show DW_AT_high_pc of 0 for an inlined function.

When reviewing the debuginfo for the linux kernel I found a large number of
inlined functions that had an offset of 0 for the DW_AT_high_pc.  This would
indicate that the inlined function has no instructions in it as the DWARF spec
in 2.17.2 Contiguous Address Range says: 

If the value of the DW_AT_high_pc is of class address, it is the address of the
first location past the last instruction associated with the entity; if it is
of class constant, the value is an unsigned integer offset which when added to
the low PC gives the address of the first location past the last instruction
associated with the entity.


I found inlined functions in the Fedora 34 linux-5.14.15 kernel that had
DW_AT_high_pc == 0 with the following command line using dwgrep
(https://pmachata.github.io/dwgrep/):

$  dwgrep /usr/lib/debug/lib/modules/5.14.15-200.fc34.x86_64/vmlinux -e '
let A := entry (?TAG_inlined_subroutine) ?AT_abstract_origin;
let LOW := ((A ?DW_AT_low_pc @DW_AT_low_pc) || (0xdeadbeef));
let HI := ((A ?DW_AT_high_pc @DW_AT_high_pc) || (0xdeadbeef));
let ENTRY := ((A ?DW_AT_low_pc @DW_AT_low_pc) || (A ?DW_AT_entry_pc
@DW_AT_entry_pc) || (0xdeadbeef));
(HI == 0) ([A name, LOW, HI, ENTRY ])' |grep \\[ | sort |more

I found that inlined functions with a single instruction to implement the
function were the ones with DW_AT_high_pc.  The kernel is rather large, so I
have a simple reproducer even-odd.c that has the function isodd that reduces to
a single instruction that demonstrates the problem when compiled with
gcc-11.2.1 and the following command line:

gcc -save-temps -g -O2 even-odd.c -o even-odd

In the output of "eu-readelf --debug-dump=info+ even-odd" see the info for the
inlined function isodd:


 [   31b]      inlined_subroutine   abbrev: 25
               abstract_origin      (ref4) [   3b3]
               entry_pc             (addr) 0x0000000000401070 <main+0x20>
               GNU_entry_view       (data1) 0
               low_pc               (addr) 0x0000000000401070 <main+0x20>
               high_pc              (data8) 0 (0x0000000000401070 <main+0x20>)
               call_file            (data1) even-odd.c (1)
               call_line            (data1) 13
               call_column          (data1) 6
               sibling              (ref4) [   34e]

Looking at the disassembled code is is the expected test of the lsb:


  401070:       40 f6 c6 01             test   $0x1,%sil
  401074:       74 13                   je     401089 <main+0x39>

Would have expected DW_AT_high_pc to be offset 4 not 0 for this example.

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-09
     Ever confirmed|0                           |1
                 CC|                            |aoliva at gcc dot gnu.org
             Target|                            |x86_64-*-*

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is likely that we have combined the bit test and the compare:

(note 77 86 78 2 t4.c:4 NOTE_INSN_INLINE_ENTRY)
(note 78 77 87 2 t4.c:6 NOTE_INSN_BEGIN_STMT)
(note 87 78 56 2 (var_location i (nil) [uninit]) NOTE_INSN_VAR_LOCATION)
(insn:TI 56 87 24 2 (set (reg:CCZ 17 flags)
        (compare:CCZ (and:QI (reg:QI 4 si [orig:83 val.1_2 ] [83])
                (const_int 1 [0x1]))
            (const_int 0 [0]))) "t4.c":13:5 502 {*testqi_1_maybe_si}
     (nil))
(jump_insn 24 56 25 2 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 33)
            (pc))) "t4.c":13:5 855 {*jcc}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 536870916 (nil)))

and thus no instruction remains in the inlined instance.  For reference, at
GIMPLE we still have

  [t4.c:4:12] # DEBUG INLINE_ENTRY isodd
  [t4.c:6:2] # DEBUG BEGIN_STMT
  [t4.c:6:11] _6 = val.1_2 & 1;
  [t4.c:13:6] # DEBUG i => NULL
  [t4.c:13:5] if (_6 != 0)

and the assembly is

        testb   $1, %sil
        je      .L2

so it's basically "unfortunate" combination of the CC set with the
bit test location.  Alex, is there a "feature" we have to capture
this somehow?

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't this TER in action?

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And, I'm afraid there is nothing in DWARF that would allow locations at
sub-instruction boundaries.  Each insn has to have just one location, so either
it gets the location of the and, or location of the comparison, but can't have
both.