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

Pedro Alves
2014-09-30T09:08:33Z

On 09/29/2014 11:53 PM, Peter Maydell wrote:
> On 29 September 2014 23:15, Pedro Alves <palves@redhat.com> wrote:
>> On 09/29/2014 07:23 PM, Peter Maydell wrote:

>> "Incorrect" may be too strong then, but understood.
>
> I wrote the QEMU patch; I'm happy to call our old
> behaviour incorrect :-)

:-)

>> I think the most flexible would be if the watchpoint
>> event reported to GDB indicated which type it got, so
>> that'd support the case an arch ever supports mixing both
>> kinds of watchpoints.
>
> Ha, I hadn't noticed that the architecture permits an
> implementation to provide both kinds (or indeed to
> have one watchpoint that might fire in either way), but
> you're right that it's theoretically allowed.

Yeah. But not just ARM -- but more flexible for all archs
and emulators.

>> Or we just forget all this, assuming that ARM chips that
>> have async watchpoints will disappear into obsolescence
>> forever soon enough. :-)
>
> There's an assertion in this LKML post from 2010:
> https://lkml.org/lkml/2010/4/14/127
> that v7 cores do actually all generate synchronous
> watchpoint exceptions (even though architecturally
> they're permitted not to). Was your test h/w a v6?

Joel's test was against qemu (without your patch).

Terry's tests were against armv7l and armv8. Both synchronous.

The report that confuses me is Gareth's:

https://sourceware.org/ml/gdb/2014-09/msg00013.html

As it sounds like he has v7-m hardware that has asynchronous
behavior. Gareth, can you confirm this, please?

Still, in any case, from that LKML post:

"v6 cores are the opposite; they only generate asynchronous
watchpoint exceptions".

So, eh!? Does your qemu patch take this into account? Seems
like it should.

In Linux's sources I see this:

/* Determine number of usable WRPs available. */
static int get_num_wrps(void)
{
/*
* On debug architectures prior to 7.1, when a watchpoint fires, the
* only way to work out which watchpoint it was is by disassembling
* the faulting instruction and working out the address of the memory
* access.
*
* Furthermore, we can only do this if the watchpoint was precise
* since imprecise watchpoints prevent us from calculating register
* based addresses.
*
* Providing we have more than 1 breakpoint register, we only report
* a single watchpoint register for the time being. This way, we always
* know which watchpoint fired. In the future we can either add a
* disassembler and address generation emulator, or we can insert a
* check to see if the DFAR is set on watchpoint exception entry
* [the ARM ARM states that the DFAR is UNKNOWN, but experience shows
* that it is set on some implementations].
*/
if (get_debug_arch() < ARM_DEBUG_ARCH_V7_1)
return 1;

So, even on Linux, on v6, etc. (< v7.1), it seems to me that we're
indeed very likely to get _asynchronous_ watchpoints reported to GDB,
and so this in GDB:

/* Watchpoints are not steppable. */
set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1);

should be skipped on < v7.1 ...

> If this is a v6-and-earlier thing I'd certainly be tempted
> to sweep the issue under the carpet...

Thanks,
Pedro Alves