Re: [PATCH 1/8] Add new test, gdb.base/loop-break.exp

[Kevin Buettner <kevinb at redhat dot com>]

The test case for loop-break.exp contains some code which performs
looping via gotos:

    volatile int v;
    ...
48        v = 0;
49        goto b;                               /* Loop 4 initial goto */
50      a:  v++;
51      b:  if (v < 3) goto a;                  /* Loop 4 condition */

While testing on arm and powerpc, I'm seeing this failure:

FAIL: gdb.base/loop-break.exp: continue to Loop 4 condition, 3 (the program exited)

The test places a breakpoint on lines 49 and 51. We expect the breakpoint
at line 49 to be hit once and the breakpoint at line 51 to be hit four
times, with v assuming the values 0, 1, 2, and 3 at successive stops
at this breakpoint.

For both arm and powerpc, the breakpoint on line 51 is being hit only
three times; the breakpoint is not being hit when v = 3.

In order to figure out what's going on, I placed breakpoints on lines
48, 49, 50, and 51.  Here's the assembly code for arm with annotations
showing the location of each breakpoint.  I've adjusted GDB's output
somewhat to better fit in 80 columns (without wrapping) along with
providing a more informative comment regarding v.

0x833c <loop_test+228>:   ldr r3, [pc, #64]   ; v		# line 48 bkpt
0x8340 <loop_test+232>:   mov     r2, #0
0x8344 <loop_test+236>:   str     r2, [r3]
0x8348 <loop_test+240>:   b       0x8364 <loop_test+268>	# line 49 bkpt
0x834c <loop_test+244>:   nop					# line 51 bkpt
0x8350 <loop_test+248>:   ldr r3, [pc, #44]   ; v		# line 50 bkpt
0x8354 <loop_test+252>:   ldr     r3, [r3]
0x8358 <loop_test+256>:   add     r3, r3, #1
0x835c <loop_test+260>:   ldr r2, [pc, #32]   ; v
0x8360 <loop_test+264>:   str     r3, [r2]
0x8364 <loop_test+268>:   ldr r3, [pc, #24]   ; v		# Loop 4 Cond
0x8368 <loop_test+272>:   ldr     r3, [r3]
0x836c <loop_test+276>:   cmp     r3, #2
0x8370 <loop_test+280>:   ble     0x834c <loop_test+244>
0x8374 <loop_test+284>:   nop

The locations for breakpoints for line 48, 49, and 50 are not surprising;
these are exactly where I would expect them to be.

The breakpoint for line 51 is placed on the nop instruction
immediately following the branch.  This nop is the branch destination
for the conditional branch at the bottom of the loop.  As such, the
breakpoint at line 51 will only be hit after evaluation of the condition,
but immediately before the increment on line 50.

The correct location for a breakpoint on line 51 is 0x8364, which I've
annotated with "Loop 4 Cond".

I've performed an analysis for powerpc too; the code being generated
is the same (modulo the differences in instruction sets) as that of
arm.

The .debug_line section contains these statements for this section of
code:

[0x0000016c]  Special opcode 68: advance Address by 8 to 0x833c and Line by 7 to 48
[0x0000016d]  Special opcode 90: advance Address by 12 to 0x8348 and Line by 1 to 49
[0x0000016e]  Special opcode 35: advance Address by 4 to 0x834c and Line by 2 to 51
[0x0000016f]  Special opcode 32: advance Address by 4 to 0x8350 and Line by -1 to 50
[0x00000170]  Special opcode 146: advance Address by 20 to 0x8364 and Line by 1 to 51

It's not clear to me why the nop is considered to be part of line 51. 
This might make (some) sense if either architecture had branch delay
slots, but to the best of my knowledge they do not.

In any case, things would work correctly if the statement at
0x0000016e were removed.

Kevin