This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/17701] New: gdb.base/consecutive.exp fails when the line table includes column information
- From: "dblaikie at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 11 Dec 2014 23:39:28 +0000
- Subject: [Bug c++/17701] New: gdb.base/consecutive.exp fails when the line table includes column information
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17701
Bug ID: 17701
Summary: gdb.base/consecutive.exp fails when the line table
includes column information
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: c++
Assignee: unassigned at sourceware dot org
Reporter: dblaikie at gmail dot com
CC: xdje42 at gmail dot com
It looks like GDB has a little difficulty with debug info including column
information in the line table (which Clang on Linux emits by default).
Take, for example:
make check RUNTESTFLAGS="CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++
CFLAGS_FOR_TARGET='-w -fstandalone-debug ' gdb.base/consecutive.exp"
(after recent changes - so you'll need a recent (>= r223872) source-built
Clang)
GDB fails the test here, because, when breaking on the 'next' instruction in
the same line, instead of getting this (which can be reproduced by passing
clang -gno-column-info):
Breakpoint 3, 0x00000000004005ab in foo () at
testsuite/gdb.base/consecutive.c:10
GDB produces:
Breakpoint 3, foo () at testsuite/gdb.base/consecutive.c:10
The difference in the line table is:
--- old.txt 2014-12-11 15:36:09.161528155 -0800
+++ new.txt 2014-12-11 15:35:44.925266367 -0800
@@ -3,7 +3,7 @@
.debug_line contents:
Line table prologue:
- total_length: 0x00000067
+ total_length: 0x00000080
version: 2
prologue_length: 0x00000048
min_inst_length: 1
@@ -31,8 +31,14 @@
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x00000000004005a0 9 0 1 0 0 is_stmt
-0x00000000004005a4 10 0 1 0 0 is_stmt
prologue_end
+0x00000000004005a4 10 10 1 0 0 is_stmt
prologue_end
+0x00000000004005ab 10 17 1 0 0 is_stmt
+0x00000000004005b2 10 24 1 0 0 is_stmt
+0x00000000004005b9 10 31 1 0 0 is_stmt
+0x00000000004005c0 10 38 1 0 0 is_stmt
+0x00000000004005c7 10 45 1 0 0 is_stmt
+0x00000000004005ce 10 52 1 0 0 is_stmt
0x00000000004005e0 14 0 1 0 0 is_stmt
-0x00000000004005e4 15 0 1 0 0 is_stmt
prologue_end
-0x00000000004005ef 16 0 1 0 0 is_stmt
-0x00000000004005fa 16 0 1 0 0 is_stmt
end_sequence
+0x00000000004005e4 15 3 1 0 0 is_stmt
prologue_end
+0x00000000004005ef 16 1 1 0 0 is_stmt
+0x00000000004005fa 16 1 1 0 0 is_stmt
end_sequence
So my guess is that GDB treated the 0x4005ab line as a separate stop point (and
didn't include the offset) because it's a separate line in the line table, even
though it has the same line number and a different column number (but GDB
didn't include the column number in the break information, just the line
number).
I guess GDB should include the offset if it's in a contiguous run of the same
line, perhaps? But I'm not sure. For now I'll XFAIL (at least in Clang's copy
of GDB 7.5 for testing purposes - might get a chance to upstream the XFAIL at
some point) this test under Clang+GDB with this bug number.
[some of the reverse debugging test cases fail with my recent improvements to
Clang's column information too, but I haven't investigated them yet - the
reverse debugging tests seem particularly fragile, as a general observation]
--
You are receiving this mail because:
You are on the CC list for the bug.