qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).