[RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint.
Pedro Alves
palves@redhat.com
Tue Sep 16 15:21:00 GMT 2014
Hi Terry, Marcus,
Can someone at ARM shed some light on this, please?
This thread is here:
https://sourceware.org/ml/gdb-patches/2014-09/msg00498.html
And the discussion started in another thread here:
https://sourceware.org/ml/gdb/2014-09/msg00000.html
I've just added a test that hopefully helps with this, btw:
https://sourceware.org/ml/gdb-patches/2014-09/msg00535.html
I'm also wondering whether Aarch64 needs adjustment as well.
Thanks,
Pedro Alves
On 09/16/2014 02:09 PM, Luis Machado wrote:
> 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
>
More information about the Gdb-patches
mailing list