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

[Pedro Alves <palves@redhat.com>]

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