[Bug c++/17701] New: gdb.base/consecutive.exp fails when the line table includes column information

["dblaikie at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.