This is the mail archive of the
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: Peter Maydell <peter dot maydell at linaro dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Terry dot Guo at arm dot com, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, "lgustavo at codesourcery dot com" <lgustavo at codesourcery dot com>, yao at codesourcery dot com, gdb-patches at sourceware dot org, Will Deacon <Will dot Deacon at arm dot com>, "Gareth, McMullin" <gareth at blacksphere dot co dot nz>
- Date: Tue, 30 Sep 2014 10:08:09 +0100
- Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint
- Authentication-results: sourceware.org; auth=none
- References: <CAFEAcA_0C+UqGwM39A4EQCQLg59fNbJ2du8rhrt++Q-pdE9rgQ at mail dot gmail dot com> <5429D9FC dot 6000509 at redhat dot com> <CAFEAcA9Dx5GE6QCktvbQF8sL1MsRxE5BmPNruSw4FsW9VyD_2w at mail dot gmail dot com>
On 09/29/2014 11:53 PM, Peter Maydell wrote:
> On 29 September 2014 23:15, Pedro Alves <firstname.lastname@example.org> wrote:
>> On 09/29/2014 07:23 PM, Peter Maydell wrote:
>> "Incorrect" may be too strong then, but understood.
> I wrote the QEMU patch; I'm happy to call our old
> behaviour incorrect :-)
>> I think the most flexible would be if the watchpoint
>> event reported to GDB indicated which type it got, so
>> that'd support the case an arch ever supports mixing both
>> kinds of watchpoints.
> Ha, I hadn't noticed that the architecture permits an
> implementation to provide both kinds (or indeed to
> have one watchpoint that might fire in either way), but
> you're right that it's theoretically allowed.
Yeah. But not just ARM -- but more flexible for all archs
>> Or we just forget all this, assuming that ARM chips that
>> have async watchpoints will disappear into obsolescence
>> forever soon enough. :-)
> There's an assertion in this LKML post from 2010:
> that v7 cores do actually all generate synchronous
> watchpoint exceptions (even though architecturally
> they're permitted not to). Was your test h/w a v6?
Joel's test was against qemu (without your patch).
Terry's tests were against armv7l and armv8. Both synchronous.
The report that confuses me is Gareth's:
As it sounds like he has v7-m hardware that has asynchronous
behavior. Gareth, can you confirm this, please?
Still, in any case, from that LKML post:
"v6 cores are the opposite; they only generate asynchronous
So, eh!? Does your qemu patch take this into account? Seems
like it should.
In Linux's sources I see this:
/* Determine number of usable WRPs available. */
static int get_num_wrps(void)
* On debug architectures prior to 7.1, when a watchpoint fires, the
* only way to work out which watchpoint it was is by disassembling
* the faulting instruction and working out the address of the memory
* Furthermore, we can only do this if the watchpoint was precise
* since imprecise watchpoints prevent us from calculating register
* based addresses.
* Providing we have more than 1 breakpoint register, we only report
* a single watchpoint register for the time being. This way, we always
* know which watchpoint fired. In the future we can either add a
* disassembler and address generation emulator, or we can insert a
* check to see if the DFAR is set on watchpoint exception entry
* [the ARM ARM states that the DFAR is UNKNOWN, but experience shows
* that it is set on some implementations].
if (get_debug_arch() < ARM_DEBUG_ARCH_V7_1)
So, even on Linux, on v6, etc. (< v7.1), it seems to me that we're
indeed very likely to get _asynchronous_ watchpoints reported to GDB,
and so this in GDB:
/* Watchpoints are not steppable. */
set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1);
should be skipped on < v7.1 ...
> If this is a v6-and-earlier thing I'd certainly be tempted
> to sweep the issue under the carpet...