This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint.
- From: Pedro Alves <palves at redhat dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Terry Guo <terry dot guo at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, lgustavo at codesourcery dot com, Joel Brobecker <brobecker at adacore dot com>, Yao Qi <yao at codesourcery dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Will Deacon <will dot deacon at arm dot com>, peter dot maydell at arm dot com, "gareth at blacksphere dot co dot nz >> Gareth McMullin" <gareth at blacksphere dot co dot nz>
- Date: Fri, 19 Sep 2014 18:31:12 +0100
- Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint.
- Authentication-results: sourceware.org; auth=none
- References: <1410786062-19274-1-git-send-email-brobecker at adacore dot com> <87bnqf2578 dot fsf at codesourcery dot com> <20140916115936 dot GM4871 at adacore dot com> <5418279A dot 1040604 at codesourcery dot com> <20140916124814 dot GO4871 at adacore dot com> <54183681 dot 3010504 at codesourcery dot com> <5418556E dot 7010502 at redhat dot com> <CAFqB+PxZM3Zb0J2HRoULU+e30jMP9OowRFsgJCjaWf7tNvagTA at mail dot gmail dot com>
Hi Marcus,
On 09/18/2014 12:40 PM, Marcus Shawcroft wrote:
> On 16 September 2014 16:21, Pedro Alves <palves@redhat.com> wrote:
>> 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.
>>
> In aarch32 execution state a watch point event is taken as a data
> abort with the PC containing the address of the faulting instruction +
> 8 irrespective of thumb mode.
So the documentation is actually wrong for thumb? Or you're
saying that for Thumb2, while it'd be 4 for Thumb 1?
If you're talking about something else, not DBGWFAR (what I think
Luis pointed out before), then can you give a pointer to where these
other watch point events are documented?
>
> The linux kernel adjusts the reported PC by subtracting 8 such that
> the ptrace interface will indicate the address of the faulting
> instruction.
Hmm. So when the data abort triggers at fault+8, the instruction
that triggered the abort hasn't actually completed, right? No memory
has changed yet.
So if nothing does the adjustment, like Gareth found out happens with
the Black Magic Probe, then we'll resume execution from the
wrong address/instruction (with the effects of the skipped instructions
missing, including the memory write...). Did I understand that
right? (Gareth, is that what you see?)
> Peter Maydell's proposed qemu patch referenced in the thread above
> appears to me to align the gdbstub behaviour in qemu with the linux
> kernel ptrace() interface behaviour.
>
> w.r.t DBGWFAR, it's use is described as deprecated in ARM ARMv7-A&R
> Issue C.c c11.11.45. It is not used by linux kernel.
Thanks,
Pedro Alves