public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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 [thread overview]
Message-ID: <bug-26243-4717-57jdNfV2Lf@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26243-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=26243
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
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 <main>:
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
46 0x400c6c
46 0x400c6e
47 0x400c7b x
47 0x400c87
48 0x400c8b x
49 0x400c94 x
49 0x400c98
50 0x400ca2 x
50 0x400ca6
50 0x400ca8
50 0x400cbb
51 0x400cce x
58 0x400cd3 x
52 0x400ce8 x
52 0x400cec
53 0x400cf0 x
53 0x400cf9
53 0x400cff
53 0x400d03
53 0x400d0b
53 0x400d18
0 0x400d1d
54 0x400d25 x
55 0x400d2f x
55 0x400d38
55 0x400d3e
55 0x400d42
55 0x400d4a
55 0x400d57
0 0x400d5c
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 ==
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
51 44 0x0000000000400c40 Y
52 45 0x0000000000400c54 Y
53 46 0x0000000000400c5e Y
54 46 0x0000000000400c63
55 46 0x0000000000400c6c
56 46 0x0000000000400c6e
57 47 0x0000000000400c7b Y
58 47 0x0000000000400c87
59 48 0x0000000000400c8b Y
60 49 0x0000000000400c94 Y
61 49 0x0000000000400c98
62 50 0x0000000000400ca2 Y
63 50 0x0000000000400ca6
64 50 0x0000000000400ca8
65 50 0x0000000000400cbb
66 51 0x0000000000400cce Y
67 58 0x0000000000400cd3 Y
68 52 0x0000000000400ce8 Y
69 52 0x0000000000400cec
70 53 0x0000000000400cf0 Y
71 53 0x0000000000400cf9
72 53 0x0000000000400cff
73 53 0x0000000000400d03
74 53 0x0000000000400d0b
75 53 0x0000000000400d18
76 END 0x0000000000400d1d
77 54 0x0000000000400d25 Y
78 55 0x0000000000400d2f Y
79 55 0x0000000000400d38
80 55 0x0000000000400d3e
81 55 0x0000000000400d42
82 55 0x0000000000400d4a
83 55 0x0000000000400d57
84 END 0x0000000000400d5c
85 46 0x0000000000400d61 Y
86 58 0x0000000000400d66 Y
87 61 0x0000000000400d80 Y
...
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_line
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 numbered
/// beginning at 1. The compiler may emit the value 0 in cases where an
/// instruction cannot be attributed to any source line.
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
= m_last_subfile != m_cu->get_builder ()->get_current_subfile ();
bool ignore_this_line
- = (file_changed && !end_sequence && m_last_address == m_address
- && !m_is_stmt && m_stmt_at_address);
+ = ((file_changed && !end_sequence && m_last_address == m_address
+ && !m_is_stmt && m_stmt_at_address)
+ || (!end_sequence && m_line == 0));
if ((file_changed && !ignore_this_line) || end_sequence)
{
...
such that we have line table:
...
47 43 0x0000000000400c30 Y
48 44 0x0000000000400c40 Y
49 45 0x0000000000400c54 Y
50 46 0x0000000000400c5e Y
51 46 0x0000000000400c63
52 46 0x0000000000400c6c
53 46 0x0000000000400c6e
54 47 0x0000000000400c7b Y
55 47 0x0000000000400c87
56 48 0x0000000000400c8b Y
57 49 0x0000000000400c94 Y
58 49 0x0000000000400c98
59 50 0x0000000000400ca2 Y
60 50 0x0000000000400ca6
61 50 0x0000000000400ca8
62 50 0x0000000000400cbb
63 51 0x0000000000400cce Y
64 58 0x0000000000400cd3 Y
65 52 0x0000000000400ce8 Y
66 52 0x0000000000400cec
67 53 0x0000000000400cf0 Y
68 53 0x0000000000400cf9
69 53 0x0000000000400cff
70 53 0x0000000000400d03
71 53 0x0000000000400d0b
72 53 0x0000000000400d18
73 54 0x0000000000400d25 Y
74 55 0x0000000000400d2f Y
75 55 0x0000000000400d38
76 55 0x0000000000400d3e
77 55 0x0000000000400d42
78 55 0x0000000000400d4a
79 55 0x0000000000400d57
80 46 0x0000000000400d61 Y
81 58 0x0000000000400d66 Y
82 61 0x0000000000400d80 Y
...
and we get the same debug session as with gdb 8.3.1.
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2020-07-15 14:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 13:11 [Bug symtab/26243] New: " vries at gcc dot gnu.org
2020-07-15 14:31 ` vries at gcc dot gnu.org [this message]
2020-07-15 14:36 ` [Bug symtab/26243] " vries at gcc dot gnu.org
2020-07-15 15:09 ` vries at gcc dot gnu.org
2020-07-15 15:20 ` andrew.burgess at embecosm dot com
2020-07-15 15:47 ` vries at gcc dot gnu.org
2020-07-15 22:05 ` vries at gcc dot gnu.org
2020-07-16 17:59 ` vries at gcc dot gnu.org
2020-07-16 19:18 ` simark at simark dot ca
2020-07-16 20:46 ` palves at redhat dot com
2020-07-16 20:51 ` palves at redhat dot com
2020-07-16 21:18 ` palves at redhat dot com
2020-07-16 22:22 ` palves at redhat dot com
2020-07-17 15:00 ` vries at gcc dot gnu.org
2020-07-20 13:00 ` andrew.burgess at embecosm dot com
2020-07-20 13:15 ` palves at redhat dot com
2020-07-24 22:23 ` cvs-commit at gcc dot gnu.org
2020-07-24 22:33 ` vries at gcc dot gnu.org
2020-09-03 5:19 ` jaydeepchauhan1494 at gmail dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-26243-4717-57jdNfV2Lf@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=gdb-prs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).