[Bug debug/99654] New: Incorrect DW_AT_entry_pc values for inlined function

[Bug debug/99654] New: Incorrect DW_AT_entry_pc values for inlined function

[wcohen at redhat dot com]

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

            Bug ID: 99654
           Summary: Incorrect DW_AT_entry_pc values for inlined function
           Product: gcc
           Version: unknown
            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 50426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50426&action=edit
Files with the source code, executables, and debuginfo demostrating
DW_AT_entry_pc issue

The generation of DW_AT_entry_pc values appears to be off.  Attached
DW_AT_entry_pc_example.tgz has files made on Fedora Rawide with the
following commands demonstrating the issue.

$ rpm -q gcc libdwarf-tools elfutils
gcc-11.0.0-0.19.fc35.x86_64
libdwarf-tools-20210305-1.fc35.x86_64
elfutils-0.183-2.fc35.x86_64
$ gcc -O3 -g test2.c -o test2_gcc --save-temp
$ dwarfdump test2_gcc > test2_gcc.dump
$ eu-readelf --debug-dump=decodedline test2_gcc > test2_gcc.lines
$ eu-readelf --debug-dump=ranges test2_gcc > test2_gcc.ranges
$ objdump -d test2_gcc > test2_gcc.dis


For the second inlined call to atoi (from the test2_gcc.dump) the
DW_AT_entry_pc looks to be off below.  Would expcet the entry to be
0x401069 at the beginning of argument setup rather than at the call to
strtol 0x401077:

< 2><0x00000171>      DW_TAG_inlined_subroutine
                        DW_AT_abstract_origin       <0x000002d1>
                        DW_AT_entry_pc              0x00401077
                        DW_AT_GNU_entry_view        2
                        DW_AT_ranges                0x00000022

      Offset of rnglists entries: 0x00000022
      [ 0] base address          0x00401069 0x00000000
      [ 1] start,end             0x00401069 0x00401074
      [ 2] start,end             0x00401077 0x0040107c
      [ 3] start,end             0x00401084 0x00401087
      [ 4] end of list                                
                        DW_AT_call_file             0x00000001
                        DW_AT_call_line             0x00000011
                        DW_AT_call_column           0x0000000b
                        DW_AT_sibling               <0x000001af>


  401069:       48 8b 7b 10             mov    0x10(%rbx),%rdi
  40106d:       ba 0a 00 00 00          mov    $0xa,%edx
  401072:       31 f6                   xor    %esi,%esi
  401074:       48 89 c5                mov    %rax,%rbp
  401077:       e8 c4 ff ff ff          call   401040 <strtol@plt>
  40107c:       8d 75 01                lea    0x1(%rbp),%esi
  40107f:       bf 10 20 40 00          mov    $0x402010,%edi
  401084:       48 89 c3                mov    %rax,%rbx
  401087:


Similiarly, things seem to be off for the inlined function f. For the
first inlined instance of f (from the test2_gcc.dump) would expect the
DW_AT_entry_pc to point to 0x40107c the first instruction assocated
with the function and where the increment happens rather than 0x401087
Looking at the line information 0x401087 is associated with the
beginning of the function, but at this point all the code associated
with the function has executed:

< 2><0x000001af>      DW_TAG_inlined_subroutine
                        DW_AT_abstract_origin       <0x000002a1>
                        DW_AT_entry_pc              0x00401087
                        DW_AT_GNU_entry_view        2
                        DW_AT_ranges                0x00000035

      Offset of rnglists entries: 0x00000035
      [ 0] base address          0x0040107c 0x00000000
      [ 1] start,end             0x0040107c 0x0040107f
      [ 2] start,end             0x00401087 0x00401087
      [ 3] end of list                                
                        DW_AT_call_file             0x00000001
                        DW_AT_call_line             0x00000012
                        DW_AT_call_column           0x00000003
                        DW_AT_sibling               <0x000001f8>


  40107c:       8d 75 01                lea    0x1(%rbp),%esi
  40107f:       bf 10 20 40 00          mov    $0x402010,%edi
  401084:       48 89 c3                mov    %rax,%rbx
  401087:       31 c0                   xor    %eax,%eax

The first inlined function g pretty much the same instruction as the
the inlined f calling it.  It also has the same DW_AT_entry_pc that is
after the instructions for the function have executed.

< 3><0x000001d4>        DW_TAG_inlined_subroutine
                          DW_AT_abstract_origin       <0x000002b9>
                          DW_AT_entry_pc              0x00401087
                          DW_AT_GNU_entry_view        4
                          DW_AT_ranges                0x00000035

      Offset of rnglists entries: 0x00000035
      [ 0] base address          0x0040107c 0x00000000
      [ 1] start,end             0x0040107c 0x0040107f
      [ 2] start,end             0x00401087 0x00401087
      [ 3] end of list                                
                          DW_AT_call_file             0x00000001
                          DW_AT_call_line             0x0000000b
                          DW_AT_call_column           0x0000000a

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[wcohen at redhat dot com]

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

--- Comment #1 from Will Cohen <wcohen at redhat dot com> ---
Jan Kratochvil at  Red Hat mentioned that the DW_AT_entry_pc values looked
reasonable when -gno-as-locview-support was added to the command line.  I
checked and they do look more reasonable.  Does this mean an issue with gas
from binutils-2.36.1-7.fc35.x86_64 ?

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[wcohen at redhat dot com]

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

--- Comment #2 from Will Cohen <wcohen at redhat dot com> ---
Created attachment 50479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50479&action=edit
assembly file compiled with -gno-as-locview-support

Resulting assembly language file generated by:

gcc -O3 -g -gno-as-locview-support -fverbose-asm -S -o test3_gcc_nolocview.s
test3.c

This can be compared to test3_gcc_locview.s that will be uploaded in a moment.

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[wcohen at redhat dot com]

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

--- Comment #3 from Will Cohen <wcohen at redhat dot com> ---
Created attachment 50480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50480&action=edit
Default assembly code generated by compiler

Default Assembly generated by compiler to compare to the
-gno-as-locview-support version that has more reasonable DW_AT_entry_pc values

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[fche at redhat dot com]

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

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
A quick diff between the two -fverbose-asm dumps confirms that the generated
object code is identical with or without the -gno-as-locview-support, but the
DW_AT_entry_pc differs.

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-30
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed then.