Re: question about ARM watchpoints

Joel Brobecker <[email protected]> writes:

Joel,
I got the same result as yours on qemu.  We have arm board, but the
kernel is too old to support hardware watchpoint, so unable to see how
it behaves on real hardware.

> That's what I wanted to try too, and will do soon. As to why we never
> heard of this before - the only affirmative answer would be from someone
> better able to undertand the docs than me.  But here's a wild guess: the
> fact that GDB stopped one instruction too late is invisible to the user
> 99% of the time. What triggered me seeing it was a change in code
> generation which caused the update to be at the penultimate instruction
> of a function. I wouldn't have seen it if the update was anywhere before
> that.

This (GDB stops 2 instructions after the variable update) causes fails
in two fails for arm-none-eabi target on qemu,

  FAIL: gdb.base/recurse.exp: continue to first instance watchpoint, second time
  FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, second time

GDB outputs:

continue^M
Continuing.^M
Hardware watchpoint 3: b^M
^M
Old value = 5^M
New value = 120^M
recurse (a=5) at ../../../../git/gdb/testsuite/gdb.base/recurse.c:21^M
21      }^M
(gdb) FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, second time

while the test expects the program stops at the line "return":

gdb_test "continue" \
	    "Continuing.*\[Ww\]atchpoint.*: b.*Old value = 5.*New value = 120.*return.*" \
	    "continue to second instance watchpoint, second time"

19        b *= recurse (a - 1);
   0x000001ca <+26>:    ldr     r3, [r7, #4]
   0x000001cc <+28>:    subs    r3, #1
   0x000001ce <+30>:    adds    r0, r3, #0
   0x000001d0 <+32>:    bl      0x1b0 <recurse>
   0x000001d4 <+36>:    adds    r2, r0, #0
   0x000001d6 <+38>:    ldr     r3, [r7, #12]
   0x000001d8 <+40>:    muls    r3, r2
   0x000001da <+42>:    str     r3, [r7, #12]  <-- memory store

20        return b;
   0x000001dc <+44>:    ldr     r3, [r7, #12]

21      }
=> 0x000001de <+46>:    adds    r0, r3, #0
   0x000001e0 <+48>:    mov     sp, r7
   0x000001e2 <+50>:    add     sp, #16

As we can see, if GDB stops one instruction after the variable update
(0x000001dc), the source line is correct, and fails will go away.

These two fails were reported on 2012-09 in codesourcery, but we didn't
analyze them until I start to fix these fails recently.

-- 
Yao (齐尧)