From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 75002385ED4D; Wed, 15 Jul 2020 14:31:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75002385ED4D From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/26243] Handle line number 0 in line table produced by clang Date: Wed, 15 Jul 2020 14:31:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 14:31:26 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26243 --- Comment #1 from Tom de Vries --- The inorder function runs from 400c30 to 400d80: ... 0000000000400c30 <_Z7inorderP4node>: 400c30: 55 push %rbp 400c31: 48 89 e5 mov %rsp,%rbp ... 400d79: e8 42 fc ff ff callq 4009c0 <_Unwind_Resume@plt> 400d7e: 66 90 xchg %ax,%ax 0000000000400d80
: 400d80: 55 push %rbp ... and has the following line table (skipping test.cpp for each entry): ... Line number Starting address View Stmt 43 0x400c30 x 44 0x400c40 x 45 0x400c54 x 46 0x400c5e x 46 0x400c63=20=20=20=20=20=20=20=20 46 0x400c6c=20=20=20=20=20=20=20=20 46 0x400c6e=20=20=20=20=20=20=20=20 47 0x400c7b x 47 0x400c87=20=20=20=20=20=20=20=20 48 0x400c8b x 49 0x400c94 x 49 0x400c98=20=20=20=20=20=20=20=20 50 0x400ca2 x 50 0x400ca6=20=20=20=20=20=20=20=20 50 0x400ca8=20=20=20=20=20=20=20=20 50 0x400cbb=20=20=20=20=20=20=20=20 51 0x400cce x 58 0x400cd3 x 52 0x400ce8 x 52 0x400cec=20=20=20=20=20=20=20=20 53 0x400cf0 x 53 0x400cf9=20=20=20=20=20=20=20=20 53 0x400cff=20=20=20=20=20=20=20=20 53 0x400d03=20=20=20=20=20=20=20=20 53 0x400d0b=20=20=20=20=20=20=20=20 53 0x400d18=20=20=20=20=20=20=20=20 0 0x400d1d=20=20=20=20=20=20=20=20 54 0x400d25 x 55 0x400d2f x 55 0x400d38=20=20=20=20=20=20=20=20 55 0x400d3e=20=20=20=20=20=20=20=20 55 0x400d42=20=20=20=20=20=20=20=20 55 0x400d4a=20=20=20=20=20=20=20=20 55 0x400d57=20=20=20=20=20=20=20=20 0 0x400d5c=20=20=20=20=20=20=20=20 46 0x400d61 x 58 0x400d66 x 61 0x400d80 x ... With gdb 8.3.1, the 0 line number entries are filtered out, because is_stmt= =3D=3D 0 for those entries: ... $ gdb -batch a.out -ex "maint expand-symtabs test.cpp" -ex "maint info line-table" INDEX LINE ADDRESS 21 43 0x0000000000400c30 22 44 0x0000000000400c40 23 45 0x0000000000400c54 24 46 0x0000000000400c5e 25 47 0x0000000000400c7b 26 48 0x0000000000400c8b 27 49 0x0000000000400c94 28 50 0x0000000000400ca2 29 51 0x0000000000400cce 30 58 0x0000000000400cd3 31 52 0x0000000000400ce8 32 53 0x0000000000400cf0 33 54 0x0000000000400d25 34 55 0x0000000000400d2f 35 46 0x0000000000400d61 36 58 0x0000000000400d66 37 61 0x0000000000400d80 ... But with current gdb, that's no longer the case: ... INDEX LINE ADDRESS IS-STMT 50 43 0x0000000000400c30 Y=20 51 44 0x0000000000400c40 Y=20 52 45 0x0000000000400c54 Y=20 53 46 0x0000000000400c5e Y=20 54 46 0x0000000000400c63=20=20=20 55 46 0x0000000000400c6c=20=20=20 56 46 0x0000000000400c6e=20=20=20 57 47 0x0000000000400c7b Y=20 58 47 0x0000000000400c87=20=20=20 59 48 0x0000000000400c8b Y=20 60 49 0x0000000000400c94 Y=20 61 49 0x0000000000400c98=20=20=20 62 50 0x0000000000400ca2 Y=20 63 50 0x0000000000400ca6=20=20=20 64 50 0x0000000000400ca8=20=20=20 65 50 0x0000000000400cbb=20=20=20 66 51 0x0000000000400cce Y=20 67 58 0x0000000000400cd3 Y=20 68 52 0x0000000000400ce8 Y=20 69 52 0x0000000000400cec=20=20=20 70 53 0x0000000000400cf0 Y=20 71 53 0x0000000000400cf9=20=20=20 72 53 0x0000000000400cff=20=20=20 73 53 0x0000000000400d03=20=20=20 74 53 0x0000000000400d0b=20=20=20 75 53 0x0000000000400d18=20=20=20 76 END 0x0000000000400d1d=20=20=20 77 54 0x0000000000400d25 Y=20 78 55 0x0000000000400d2f Y=20 79 55 0x0000000000400d38=20=20=20 80 55 0x0000000000400d3e=20=20=20 81 55 0x0000000000400d42=20=20=20 82 55 0x0000000000400d4a=20=20=20 83 55 0x0000000000400d57=20=20=20 84 END 0x0000000000400d5c=20=20=20 85 46 0x0000000000400d61 Y=20 86 58 0x0000000000400d66 Y=20 87 61 0x0000000000400d80 Y=20 ... The line 0 entries are represented here as "END" or end-of-sequence, because that's the semantics of line number 0 internally in GDB. So, the question is: what is the semantics of a line 0 entry in a .debug_li= ne table? The dwarf standard does not give it any special meaning. In the llvm source code, we find in ./include/llvm/DebugInfo/DWARF/DWARFDebugLine.h: ... /// An unsigned integer indicating a source line number. Lines are numb= ered=20 /// beginning at 1. The compiler may emit the value 0 in cases where an= =20=20=20=20=20 /// instruction cannot be attributed to any source line.=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uint32_t Line; ... So, apparently clang/llvm decided on this semantics. The easiest thing to do seems to be ignore this entry during reading: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 558fad74f8..0bbd04b84f 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -20300,8 +20300,9 @@ lnp_state_machine::record_line (bool end_sequence) bool file_changed =3D m_last_subfile !=3D m_cu->get_builder ()->get_current_subfi= le (); bool ignore_this_line - =3D (file_changed && !end_sequence && m_last_address =3D=3D m_a= ddress - && !m_is_stmt && m_stmt_at_address); + =3D ((file_changed && !end_sequence && m_last_address =3D=3D m_= address + && !m_is_stmt && m_stmt_at_address) + || (!end_sequence && m_line =3D=3D 0)); if ((file_changed && !ignore_this_line) || end_sequence) { ... such that we have line table: ... 47 43 0x0000000000400c30 Y=20 48 44 0x0000000000400c40 Y=20 49 45 0x0000000000400c54 Y=20 50 46 0x0000000000400c5e Y=20 51 46 0x0000000000400c63=20=20=20 52 46 0x0000000000400c6c=20=20=20 53 46 0x0000000000400c6e=20=20=20 54 47 0x0000000000400c7b Y=20 55 47 0x0000000000400c87=20=20=20 56 48 0x0000000000400c8b Y=20 57 49 0x0000000000400c94 Y=20 58 49 0x0000000000400c98=20=20=20 59 50 0x0000000000400ca2 Y=20 60 50 0x0000000000400ca6=20=20=20 61 50 0x0000000000400ca8=20=20=20 62 50 0x0000000000400cbb=20=20=20 63 51 0x0000000000400cce Y=20 64 58 0x0000000000400cd3 Y=20 65 52 0x0000000000400ce8 Y=20 66 52 0x0000000000400cec=20=20=20 67 53 0x0000000000400cf0 Y=20 68 53 0x0000000000400cf9=20=20=20 69 53 0x0000000000400cff=20=20=20 70 53 0x0000000000400d03=20=20=20 71 53 0x0000000000400d0b=20=20=20 72 53 0x0000000000400d18=20=20=20 73 54 0x0000000000400d25 Y=20 74 55 0x0000000000400d2f Y=20 75 55 0x0000000000400d38=20=20=20 76 55 0x0000000000400d3e=20=20=20 77 55 0x0000000000400d42=20=20=20 78 55 0x0000000000400d4a=20=20=20 79 55 0x0000000000400d57=20=20=20 80 46 0x0000000000400d61 Y=20 81 58 0x0000000000400d66 Y=20 82 61 0x0000000000400d80 Y=20 ... and we get the same debug session as with gdb 8.3.1. --=20 You are receiving this mail because: You are on the CC list for the bug.=