From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 926E6385B833; Fri, 3 Apr 2020 16:13:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 926E6385B833 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585930429; bh=MhmMKRJHYEaXcLB8GYxRqFNLnZHgS2L7WcCFGMLrWUc=; h=From:To:Subject:Date:From; b=oIwgHpB9iheGXYGfBH3bjIq/5i4xizQswNcSorW8NkPGiVZl0cTSc5yxhNYuvtcub Y1OCj30DB/VRvCU2OWJu1oyp3WANM7oyFZNud+G94VGwPlh5rhfGLMRnOrf7uydaNZ cYCpEpP2miKk1qCOHydNTyNT4edt9xaLOh8A+bfc= From: "andrew.burgess at embecosm dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/94474] New: Incorrect DWARF range information for inlined function Date: Fri, 03 Apr 2020 16:13:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andrew.burgess at embecosm dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:13:49 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94474 Bug ID: 94474 Summary: Incorrect DWARF range information for inlined function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: andrew.burgess at embecosm dot com Target Milestone: --- Created attachment 48190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D48190&action=3Dedit Bug reproducer. Download the attached file, then: tar -xf gcc-ranges-bugs.tar.xz cd gcc-ranges-bugs make The problem is described in the included README file, the contents of which= I will include below. -- * Overview + The issues are present in all compilations, but v3 uses what I think might be the "best" debug flags. + Tested on GCC 9.2.0 and GCC from master branch (2020-02-05). + These bugs were encountered when trying to improve is-stmt support within GDB. + This bug report has a bit of history. Originally there was a GCC patch here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html and a reply here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html This led to a GDB patch here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html which in turn led to a different GDB patch (adding is-stmt support), here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html + As suggested in the 2019-10 GCC follow up, I have tried compiling with =3D-gno-statement-frontiers -gno-variable-location-views=3D, and currently the debug experience is better, but if I hack GDB to "fix" the bugs below while reading in the DWARF then I get just as good a debug experience with GCC's default flags. + In the included Makefile I build the test 4 times, version 3 is possibly the most interesting, as this explicitly switches on what I think are the "best" features for location tracking. However, the same bugs are present in v1 and v2 (see Makefile for flag differences). Version 4 compiles with the =3D-gno-*=3D flags above, and is included for reference. As I've already said, these bugs are not present there. + All of the analysis below references the output files =3Dtest-v3=3D, =3Ddissas-v3=3D, =3Ddwarf-v3=3D, and =3Dlines-v3=3D. * Issue 1 + The function =3Dtree_check=3D is inlined 3 times. + The first =3DDW_TAG_inlined_subroutine=3D looks like this: #+BEGIN_EXAMPLE <2><8db>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) <8dc> DW_AT_abstract_origin: <0x9cc> <8e0> DW_AT_entry_pc : 0x400545 <8e8> Unknown AT value: 2138: 3 <8e9> DW_AT_ranges : 0x30 <8ed> DW_AT_call_file : 1 <8ee> DW_AT_call_line : 52 <8ef> DW_AT_call_column : 10 <8f0> DW_AT_sibling : <0x92f> #+END_EXAMPLE This references some =3D.debug_ranges=3D data that looks like this: #+BEGIN_EXAMPLE 00000030 0000000000400545 0000000000400545 (start =3D=3D end) 00000030 0000000000400549 0000000000400553 00000030 0000000000400430 0000000000400435 00000030 #+END_EXAMPLE + Notice that =3D0x400545=3D is /not/ part of the range for the inlined function as the range =3D=3D0x400545=3D to =3D0x400545=3D is an empty r= ange, containing no bytes (see DWARF-4, 2.17.3: Non-Contiguous Address Ranges). + The =3DDW_AT_entry_pc=3D points to =3D0x400545=3D. + DWARF-4, 2.18: Entry Address, says: #+BEGIN_QUOTE Any debugging information entry describing an entity that has a range of code addresses, which includes compilation units, module initialization, subroutines, ordinary blocks, try/catch blocks, and the like, may have a DW_AT_entry_pc attribute to indicate the first executable instruction within that range of addresses. #+END_QUOTE I believe this means that the =3DDW_AT_entry_pc=3D should reference an address that is within the range of addresses associated with the inlined subroutine. + The particular problem this causes for GDB is that the decoded line table (see =3Dlines-v3=3D) includes: #+BEGIN_EXAMPLE ./step-and-next-inline.h:[++] step-and-next-inline.h 32 0x400545= =20=20=20=20=20 3 x step-and-next-inline.h 34 0x400545= =20=20=20=20=20 4 x #+END_EXAMPLE GDB then stops for these lines (that are part of the inlined function, at an address that is not part of the inlined functions address range. + An idea solution for GDB would be to include the address =3D0x400545=3D within the address range of the inlined function, and when I earlier said I hacked GDB to "fix" this bug, this is what I did, extending the range entry starting at =3D0x400549=3D to instead start at =3D0x400545=3D. * Issue 2 + Looking at the other end of the range now, there's a range =3D0x400549=3D to =3D0x400553=3D, again according to 'DWARF-4, 2.17.3: Non-Contiguous Address Ranges' anything at =3D0x400553=3D is not within this range. + Looking at the decoded line table (see =3Dlines-v3=3D) we see this: #+BEGIN_EXAMPLE ./step-and-next-inline.h:[++] step-and-next-inline.h 32 0x400545= =20=20=20=20=20 3 x step-and-next-inline.h 34 0x400545= =20=20=20=20=20 4 x ./step-and-next-inline.cc:[++] step-and-next-inline.cc 50 0x400545= =20=20=20=20=20 5 ./step-and-next-inline.h:[++] step-and-next-inline.h 34 0x400549= =20=20=20=20=20 6 step-and-next-inline.h 34 0x40054b= =20=20=20=20=20 7 step-and-next-inline.h 36 0x400553= =20=20=20=20=20 8 x step-and-next-inline.h 37 0x400553= =20=20=20=20=20 9 x step-and-next-inline.h 37 0x400553= =20=20=20=20=20 10 ./step-and-next-inline.cc:[++] step-and-next-inline.cc 52 0x400553= =20=20=20=20=20 11 step-and-next-inline.cc 52 0x400556= =20=20=20=20=20 12 #+END_EXAMPLE + Notice that lines 36 and 37 of step-and-next-inline.h are listed (with is-stmt =3D true) as being at =3D0x400553=3D. This is upsets GDB quite a bit as stopping at these addresses reports a line from the inilned function, but, as this is outside of the range associated with the inlined function, GDB doesn't understand that we are in the inlined frame. + This miss-placing of lines 36 and 37 is repeated for all three inlined instances. + I think the ideal solution for GDB would be to include that address within the range, or if that's not possible, or not appropriate, don't have those lines marked as 'is-stmt =3D true', then at least GDB would not try to stop their. When I said earlier I hacked GDB to "fix" this issue, this is what I did, I extended the upper bound for all three inline functions by 3 bytes (to cover one more instruction).=