Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives

[Pedro Alves <palves at redhat dot com>]

On 06/08/2016 06:54 PM, Pedro Alves wrote:
> How is this better than making it the responsibility of the
> stub to report a stop data address that is within the address
> range that gdb requested to watch, in the first place?

I thought of a case where this is the wrong thing to do.
(Alternative below.)

The same example as before: e.g., a machine that only supports
watching 32-bit-aligned words.  Then with:

union
{
  char buf[4];
  uint32_t force_align;
} global;

(gdb) watch global.buf[1];
Hardware watchpoint 1 ...
(gdb) watch global.buf[3];
Hardware watchpoint 2 ...

... if the program writes to global.buf[3], and the target
reports a memory access to 'global.buf + 1' (because that's the
first watchpoint in its own watchpoint list that overlaps
the global.buf[0]..global.buf[3] range (what is really being
watched)), gdb will believe that watchpoint 1 triggered, notice
the value didn't change, and thus incorrectly ignore the watchpoint hit.

So I'm now thinking that the best is to extend the RSP somehow.

I think that my preference is for the target to report a
memory range instead of a single address in the watchpoint 
stop reply.  Like, e.g., if an access to address 10000006 triggers,
but all the target knows is that some address between 10000004
and 10000008 was accessed, it reports:

  T05 watch:10000004-10000008

instead of:

  T05 watch:10000006

( or maybe T05 watch:10000004;watch-end:10000008 )

This should be easy to implement in the target side, and
is practically stateless (a stub that just forwards requests
to a lower level debug api doesn't have to remember
the addresses gdb requested).

Then the corresponding target methods in gdb would work with an
address range instead of a single address too.  E.g.,
target_watchpoint_addr_within_range would be replaced by
a range overlap check.

If the target knows the process stopped for a watchpoint, but
doesn't know the address that triggered, then it could report
the whole address space as range:

  T05 watch:00000000-ffffffff

Note that it's not possible currently for a remote stub to tell gdb
that it doesn't know the address that trapped, even though the
target_ops:target_stopped_data_address method supports
returning false, and some native targets do make use of it.

Alternatively, since we're extending the packet anyway, we
can make the address optional, thus making these equivalent:

  T05 watch:00000000-ffffffff
  T05 watch:

Alternatively, I though we could add a new qSupported feature value
that informs gdb of what is the watchpoint alignment and size
restriction, but I'm not so keen on that since the alignment
restriction may depend on mode (e.g., 32-bit vs 64-bit inferior),
or on the size of the area being watched, or some more complicated rule.

Thanks,
Pedro Alves