[RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint.

[Pedro Alves]

Hi Marcus,

On 09/18/2014 12:40 PM, Marcus Shawcroft wrote:
> On 16 September 2014 16:21, Pedro Alves <palves@redhat.com> wrote:
>> Hi Terry, Marcus,
>>
>> Can someone at ARM shed some light on this, please?
>>
>> This thread is here:
>>
>>  https://sourceware.org/ml/gdb-patches/2014-09/msg00498.html
>>
>> And the discussion started in another thread here:
>>
>>   https://sourceware.org/ml/gdb/2014-09/msg00000.html
>>
>> I've just added a test that hopefully helps with this, btw:
>>
>>  https://sourceware.org/ml/gdb-patches/2014-09/msg00535.html
>>
>> I'm also wondering whether Aarch64 needs adjustment as well.
>>

> In aarch32 execution state a watch point event is taken as a data
> abort with the PC containing the address of the faulting instruction +
> 8 irrespective of thumb mode.

So the documentation is actually wrong for thumb?  Or you're
saying that for Thumb2, while it'd be 4 for Thumb 1?

If you're talking about something else, not DBGWFAR (what I think
Luis pointed out before), then can you give a pointer to where these
other watch point events are documented?

> 
> The linux kernel adjusts the reported PC by subtracting 8 such that
> the ptrace interface will indicate the address of the faulting
> instruction.

Hmm.  So when the data abort triggers at fault+8, the instruction
that triggered the abort hasn't actually completed, right?  No memory
has changed yet.

So if nothing does the adjustment, like Gareth found out happens with
the Black Magic Probe, then we'll resume execution from the
wrong address/instruction (with the effects of the skipped instructions
missing, including the memory write...).  Did I understand that
right?  (Gareth, is that what you see?)

> Peter Maydell's proposed qemu patch referenced in the thread above
> appears to me to align the gdbstub behaviour in qemu with the linux
> kernel ptrace() interface behaviour.
> 
> w.r.t DBGWFAR, it's use is described as deprecated in  ARM ARMv7-A&R
> Issue C.c  c11.11.45. It is not used by linux kernel.

Thanks,
Pedro Alves