aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2020-07-25 00:23:06 +0200
committerTom de Vries <tdevries@suse.de>2020-07-25 00:23:06 +0200
commit876518dd0a0b6fd6f4ad0a0b247db0d6a267db27 (patch)
treef2232c223a68f149048a9705568e6e16928a2a66 /gdb/dwarf2
parentf6720b1cfe8f70ef5631b390780dfb53166e9ff2 (diff)
downloadgdb-876518dd0a0b6fd6f4ad0a0b247db0d6a267db27.zip
gdb-876518dd0a0b6fd6f4ad0a0b247db0d6a267db27.tar.gz
gdb-876518dd0a0b6fd6f4ad0a0b247db0d6a267db27.tar.bz2
[gdb/symtab] Ignore zero line table entries
The DWARF standard states for the line register in the line number information state machine the following: ... 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. ... So, it's possible to have a zero line number in the DWARF line table. This is currently not handled by GDB. The zero value is read in as any other line number, but internally the zero value has a special meaning: end-of-sequence, so the line table entry ends up having a different interpretation than intended in some situations. I've created a test-case where various aspects are tested, which has these 4 interesting tests. 1. Next-step through a zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next 2. Next-step through a zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next 3. Show source location at zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 4. Show source location at zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 And we have the following results: 8.3.1, 9.2: ... FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt field": ... PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting", master: FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243, where clang emits zero line numbers. The way to fix all tests is to make sure line number zero internally doesn't clash with special meaning values, and by handling it appropriately everywhere. That however looks too intrusive for the GDB 10 release. Instead, we decide to ensure defined behaviour for line number zero by ignoring it. This gives us back the test results from before commit d8cc8af6a1, fixing PR26243. We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb 10 the cost for having defined behaviour. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line entries. gdb/testsuite/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * gdb.dwarf2/dw2-line-number-zero.c: New test. * gdb.dwarf2/dw2-line-number-zero.exp: New file.
Diffstat (limited to 'gdb/dwarf2')
-rw-r--r--gdb/dwarf2/read.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 39ed455..4e70dcc 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -20437,8 +20437,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)
{