In this simple test case, setting a breakpoint at the start of the second for
loop is ineffective, even when compiling with -O0.
int
main(int argc, char **argv)
{
int j;
unsigned char block[6];
for (j = 0; j < 4; j++)
block[j] = (unsigned char) j;
for (; j < 6; j++)
block[j] = (unsigned char) j;
}
The second for loop is compiled into code like this:
goto L1;
L2:
block[j] = (unsigned char) j;
j += 1;
L1:
if (j < 6)
goto L2;
The first goto has no line number information. The increment to j is marked
with the line of the start of the for loop (as it should be). The effect is
that if you use gdb on the program and set a breakpoint on the start of the for
loop, that breakpoint will not be hit until the "j += 1" statement is executed,
at which point the loop has already been executed once. This can be seen in
gdb, or by using objdump -dl.
This would be perfectly understandable when optimizing, of course, but -O0 -g
should support maximum debuggability, and should certainly permit setting a
breakpoint at the start of a loop. Presumably the fix is to mark the "goto L1"
statement with the appropriate line number.
This works correctly with gcc 3.4.3, which generates different code in any case.
--
Summary: [4.0/4.1 Regression] Poor -O0 debug information for for
loops with no initializer
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22057
