From: Peter Maydell <peter.maydell@linaro.org>
To: Pedro Alves <palves@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
Marcus Shawcroft <marcus.shawcroft@gmail.com>,
Terry.Guo@arm.com, Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
"lgustavo@codesourcery.com" <lgustavo@codesourcery.com>,
yao@codesourcery.com, gdb-patches@sourceware.org,
Will Deacon <Will.Deacon@arm.com>,
"Gareth, McMullin" <gareth@blacksphere.co.nz>
Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint
Date: Tue, 30 Sep 2014 10:01:00 -0000 [thread overview]
Message-ID: <CAFEAcA9CFb+NbpMc_O1e2VQHngG0t481STay7c9-p1DQFR8jTA@mail.gmail.com> (raw)
In-Reply-To: <542A72F9.5090203@redhat.com>
On 30 September 2014 10:08, Pedro Alves <palves@redhat.com> wrote:
> On 09/29/2014 11:53 PM, Peter Maydell wrote:
>> There's an assertion in this LKML post from 2010:
>> https://lkml.org/lkml/2010/4/14/127
>> 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:
>
> https://sourceware.org/ml/gdb/2014-09/msg00013.html
>
> As it sounds like he has v7-m hardware that has asynchronous
> behavior. Gareth, can you confirm this, please?
In general it's unwise to assume that statements
about the ARM A and R profiles carry across to M
profile... v7M profile watchpoints are rather
different from v7AR watchpoints in terms of how you
set them, how they're reported, etc, and they're
always asynchronous (other insns may execute after
the one which triggers the wp before the debug event
fires).
> Still, in any case, from that LKML post:
>
> "v6 cores are the opposite; they only generate asynchronous
> watchpoint exceptions".
>
> So, eh!? Does your qemu patch take this into account? Seems
> like it should.
My QEMU patch is for the built in gdbstub, which is
completely different code to the emulation of the
CPU's own architected debug hardware. (We implement
the latter only for v7 and above, not v6.)
It doesn't seem very sensible to me to deliberately
provide unhelpful asynchronous watchpoint support
on v6-and-lower guest CPUs just because that's what
the hardware does, especially since it would mean we
wouldn't interoperate with current gdb. (Similarly,
we provide watchpoint support in our stub even if
the CPU we're emulating has no watchpoint support
of its own at all. Think of us as like a JTAG probe.)
> Now I'm confused on the mention of the Linux kernel
> subtracting 8 from the PC to help GDB. I can't find that
> anywhere in the kernel's sources.
This is a reference to the standard ARM exception
entry behaviour where the value saved to the link
register may be +2, +4 or +8 from the "preferred
return address" for the exception. The kernel handles
this via a 'vector_stub' macro that adjusts the
value read from LR so the rest of the kernel can
deal simply in preferred return addresses. Since
sync. watchpoints are a kind of data abort they
go through here, with a correction value of 8:
http://lxr.free-electrons.com/source/arch/arm/kernel/entry-armv.S#L1043
thanks
-- PMM
next prev parent reply other threads:[~2014-09-30 10:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 18:23 Peter Maydell
2014-09-29 22:15 ` Pedro Alves
2014-09-29 22:54 ` Peter Maydell
2014-09-30 9:08 ` Pedro Alves
2014-09-30 9:18 ` Will Deacon
2014-09-30 10:07 ` Pedro Alves
2014-09-30 10:18 ` Peter Maydell
2014-09-30 10:38 ` Pedro Alves
2014-09-30 10:01 ` Peter Maydell [this message]
2014-09-30 10:34 ` Pedro Alves
2014-09-30 12:54 ` Pedro Alves
2014-09-30 13:50 ` Joel Brobecker
2014-09-30 14:11 ` Pedro Alves
2014-09-30 14:26 ` Joel Brobecker
2014-09-30 14:50 ` Peter Maydell
2014-09-30 8:57 ` Will Deacon
2014-09-30 9:04 ` Will Deacon
2014-09-30 9:14 ` Pedro Alves
2014-09-30 9:24 ` Will Deacon
-- strict thread matches above, loose matches on Subject: below --
2014-09-15 13:01 Joel Brobecker
2014-09-16 11:12 ` Yao Qi
2014-09-16 11:59 ` Joel Brobecker
2014-09-16 12:05 ` Luis Machado
2014-09-16 12:48 ` Joel Brobecker
2014-09-16 13:09 ` Luis Machado
2014-09-16 15:21 ` Pedro Alves
2014-09-18 11:40 ` Marcus Shawcroft
2014-09-19 17:31 ` Pedro Alves
2014-09-29 17:51 ` Joel Brobecker
2014-09-29 17:57 ` Luis Machado
2014-09-29 21:04 ` Pedro Alves
2014-09-30 8:54 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA9CFb+NbpMc_O1e2VQHngG0t481STay7c9-p1DQFR8jTA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=Marcus.Shawcroft@arm.com \
--cc=Terry.Guo@arm.com \
--cc=Will.Deacon@arm.com \
--cc=brobecker@adacore.com \
--cc=gareth@blacksphere.co.nz \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=marcus.shawcroft@gmail.com \
--cc=palves@redhat.com \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox