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

[Luis Machado <lgustavo at codesourcery dot com>]

On 09/16/2014 09:48 AM, Joel Brobecker wrote:
> > > I think the experiments that were run showed that QEMU is in fact
> > > correct and should NOT be changed.
> >
> > Do we know what the Linux kernel's behavior on this one is? I wonder
> > what the stopped data address shows.
> >
> > Someone with access to a board with a relatively new kernel could
> > try that and rule it out, otherwise we risk fixing something for
> > QEMU/bare metal and breaking things for Linux.
>
> When I tested on GNU/Linux, watchpoints simply did not work
> (silently ignored, no signal).  I was using an old kernel (2012),
> though; but that's all I had access to.  But, all in all, baremetal
> should be our most reliable source of info, though,no? - no software
> layer to murky the waters.

It is hard to tell. ARM's documentation is not clear. For example, this 
is probably where the stopped data address should be coming from:

--

WFAR - Watchpoint Fault Address Register

The WFAR is updated to indicate the address of the instruction that 
accessed the watchpointed address:

- the address of the instruction + 8 in ARM state
- the address of the instruction + 4 in Thumb® state

--

So it seems in line with what we are seeing? The program being trapped 
two instructions after the data fault?

If it stops just a single instruction after the data fault, then someone 
(probe, emulator or kernel) may be trying to help GDB by decrementing 
the data fault address.

Luis