From: Cary Coutant <ccoutant@google.com>
To: gdb-patches@sourceware.org
Subject: DWARF is_stmt flag (revisited)
Date: Tue, 16 Jun 2009 18:39:00 -0000 [thread overview]
Message-ID: <c17be2b30906161139x1c37b0fcofe17a1ede443c2b3@mail.gmail.com> (raw)
Daniel Jacobowitz posted a patch for discussion last October to make
gdb ignore line table rows where is_stmt == 0:
http://sourceware.org/ml/gdb-patches/2008-10/msg00055.html
There are still a couple of remaining testsuite failures that are
triggered by the new discriminator support in gcc, and fixing these
failures is going to require that gcc emit line table entries where
is_stmt == 0. The problem is that the new line table row that gcc adds
to change the discriminator is now seen as a new potential breakpoint
location, and a place to stop when single-stepping. The solution is to
change gcc so that any new rows to set the discriminator (that would
not otherwise have been emitted) should have is_stmt == 0, and for gdb
to ignore such rows.
The patch below is almost the same as Daniel's original patch; I also
fixed a bug where the basic_block flag was being initialized to the
wrong value after a special opcode.
Longer term, I think that gdb will need to record the is_stmt flag
with each line table row, so that it can provide accurate pc -> line
number mappings for optimized code, while still ignoring !is_stmt
lines when setting breakpoints and single-stepping. The compiler will
eventually need to start using the is_stmt flag when scheduling causes
the line number to hop around, so that we don't stop multiple times on
one line of code.
Tested on x86_64. No new regressions with a compiler that does not set
is_stmt == 0. OK for trunk?
-cary
* dwarf2read.c (dwarf_decode_lines): Ignore rows where is_stmt is 0.
Set basic_block to 0 after a special opcode.
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.308
diff -u -p -r1.308 dwarf2read.c
--- dwarf2read.c 13 Jun 2009 04:23:34 -0000 1.308
+++ dwarf2read.c 16 Jun 2009 18:26:52 -0000
@@ -7318,7 +7318,7 @@ dwarf_decode_lines (struct line_header *
else
{
lh->file_names[file - 1].included_p = 1;
- if (!decode_for_pst_p)
+ if (!decode_for_pst_p && is_stmt)
{
if (last_subfile != current_subfile)
{
@@ -7331,7 +7331,7 @@ dwarf_decode_lines (struct line_header *
check_cu_functions (address, cu));
}
}
- basic_block = 1;
+ basic_block = 0;
}
else switch (op_code)
{
@@ -7396,7 +7396,7 @@ dwarf_decode_lines (struct line_header *
else
{
lh->file_names[file - 1].included_p = 1;
- if (!decode_for_pst_p)
+ if (!decode_for_pst_p && is_stmt)
{
if (last_subfile != current_subfile)
{
next reply other threads:[~2009-06-16 18:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 18:39 Cary Coutant [this message]
2009-06-23 18:36 ` Cary Coutant
2009-06-23 18:49 ` Daniel Jacobowitz
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=c17be2b30906161139x1c37b0fcofe17a1ede443c2b3@mail.gmail.com \
--to=ccoutant@google.com \
--cc=gdb-patches@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