This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]