From: Sergey Fedorov <serge.fdrv@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] target-arm: Fix CPU breakpoint handling
Date: Fri, 9 Oct 2015 16:53:21 +0300 [thread overview]
Message-ID: <5617C6D1.5080608@gmail.com> (raw)
In-Reply-To: <CAFEAcA_DYm+Jz8tEbNmz6u+oZQhZ1vybOjXsEgBTsf8geT7UOQ@mail.gmail.com>
On 08.10.2015 21:40, Peter Maydell wrote:
> On 28 September 2015 at 11:07, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> A QEMU breakpoint match is not definitely an architectural breakpoint
>> match. If an exception is generated unconditionally during translation,
>> it is hardly possible to ignore it in the debug exception handler.
>>
>> Generate a call to a helper to check CPU breakpoints and raise an
>> exception only if any breakpoint matches architecturally.
>>
>> Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com>
>> diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
>> index ec0936c..426229f 100644
>> --- a/target-arm/translate-a64.c
>> +++ b/target-arm/translate-a64.c
>> @@ -11082,11 +11082,14 @@ void gen_intermediate_code_internal_a64(ARMCPU *cpu,
>> if (unlikely(!QTAILQ_EMPTY(&cs->breakpoints))) {
>> QTAILQ_FOREACH(bp, &cs->breakpoints, entry) {
>> if (bp->pc == dc->pc) {
>> - gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
>> - /* Advance PC so that clearing the breakpoint will
>> - invalidate this TB. */
>> - dc->pc += 2;
>> - goto done_generating;
>> + if (bp->flags & BP_CPU) {
>> + gen_helper_check_breakpoints(cpu_env);
>> + } else {
>> + gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
> We shouldn't just continue here, because now we'll try to generate the
> code for the instruction even in the "we know this will always be a bp"
> case. Also, you've dropped the "advance PC" part which we need so this
> TB is not zero length.
Actually, I was going to do the same way as some architectures (e.g.
alpha) did: always translate one instruction so that TB size is
determined by actual instruction decoding. At least, it makes sense for
AArch32 where we can have 16/32-bit insns. If we advance PC incorrectly,
we will get "Disassembler disagrees with translator over instruction
decoding" warning messages when in_asm log enabled. I can rewrite it
with PC advancement, but at least, I would like to change the
advancement to 4 bytes for A64 translation.
Best regards,
Sergey
>
>> + }
>> + /* End the TB early; it's likely not going to be executed */
>> + dc->is_jmp = DISAS_UPDATE;
> gen_exception_internal_insn sets is_jmp to DISAS_EXC, and then this
> overrides it; so this line should go inside the "is this a BP_CPU bp?"
> if clause. (I think the effect is just that we pointlessly generate some
> unreachable code after the exception generating call.)
>
>> + break;
>> }
>> }
>> }
>> @@ -11209,7 +11212,6 @@ void gen_intermediate_code_internal_a64(ARMCPU *cpu,
>> }
>> }
>>
>> -done_generating:
>> gen_tb_end(tb, num_insns);
>>
>> #ifdef DEBUG_DISAS
>> diff --git a/target-arm/translate.c b/target-arm/translate.c
>> index 84a21ac..405d6d0 100644
>> --- a/target-arm/translate.c
>> +++ b/target-arm/translate.c
>> @@ -11328,11 +11328,14 @@ static inline void gen_intermediate_code_internal(ARMCPU *cpu,
>> if (unlikely(!QTAILQ_EMPTY(&cs->breakpoints))) {
>> QTAILQ_FOREACH(bp, &cs->breakpoints, entry) {
>> if (bp->pc == dc->pc) {
>> - gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
>> - /* Advance PC so that clearing the breakpoint will
>> - invalidate this TB. */
>> - dc->pc += 2;
>> - goto done_generating;
>> + if (bp->flags & BP_CPU) {
>> + gen_helper_check_breakpoints(cpu_env);
>> + } else {
>> + gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
>> + }
>> + /* End the TB early; it's likely not going to be executed */
>> + dc->is_jmp = DISAS_UPDATE;
> Similar comments here.
>
> Annoying corner case which I don't think we need to handle necessarily:
> if you set a breakpoint on a 32-bit Thumb instruction which spans a page
> boundary, and the second page is not present, we will end up taking the
> page fault when I think we should take the breakpoint. I can't think
> of a way to get that right, so just commenting that it isn't handled
> right would do.
>
>> + break;
>> }
>> }
>> }
>> --
>> 1.9.1
>>
> Otherwise I think this is the right approach.
>
> thanks
> -- PMM
next prev parent reply other threads:[~2015-10-09 13:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-28 10:07 [Qemu-devel] [PATCH v2 0/2] target-arm: Fix breakpoint handling Sergey Fedorov
2015-09-28 10:07 ` [Qemu-devel] [PATCH v2 1/2] target-arm: Fix GDB " Sergey Fedorov
2015-10-08 18:20 ` Peter Maydell
2015-09-28 10:07 ` [Qemu-devel] [PATCH v2 2/2] target-arm: Fix CPU " Sergey Fedorov
2015-10-08 18:40 ` Peter Maydell
2015-10-09 13:53 ` Sergey Fedorov [this message]
2015-10-09 14:00 ` Peter Maydell
2015-10-09 14:03 ` Sergey Fedorov
2015-10-09 13:59 ` Sergey Fedorov
2015-10-09 14:04 ` Peter Maydell
2015-10-09 15:55 ` Sergey Fedorov
2015-10-09 15:59 ` Peter Maydell
2015-10-09 16:31 ` Sergey Fedorov
2015-10-12 12:41 ` Sergey Fedorov
2015-10-12 13:22 ` Peter Maydell
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=5617C6D1.5080608@gmail.com \
--to=serge.fdrv@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).