This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/8] Add new test, gdb.base/loop-break.exp
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 21 Sep 2015 17:11:24 -0700
- Subject: Re: [PATCH 1/8] Add new test, gdb.base/loop-break.exp
- Authentication-results: sourceware.org; auth=none
- References: <20150818235334 dot 1afb0c85 at pinnacle dot lan> <20150818235756 dot 23c9d7db at pinnacle dot lan>
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