All of lore.kernel.org
 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] target-arm: fix CPU breakpoint handling
Date: Fri, 18 Sep 2015 20:14:10 +0300	[thread overview]
Message-ID: <55FC4662.60901@gmail.com> (raw)
In-Reply-To: <CAFEAcA93S8K5CuNYBg3fuf3vkPuY1ujL5XeU-P6RBTz9_cC_2Q@mail.gmail.com>

On 18.09.2015 19:36, Peter Maydell wrote:
> On 18 September 2015 at 17:33, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> On 18.09.2015 17:14, Peter Maydell wrote:
>>> On 18 September 2015 at 15:07, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>>>> On 18.09.2015 16:50, Peter Maydell wrote:
>>>>> On 14 September 2015 at 11:51, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>>>>>> --- a/target-arm/translate-a64.c
>>>>>> +++ b/target-arm/translate-a64.c
>>>>>> @@ -11000,11 +11000,13 @@ 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);
>>>>>> +                        break;
>>>>>> +                    } else {
>>>>>> +                        gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
>>>>>> +                        goto done_generating;
>>>>>> +                    }
>>>>> You seem to have dropped the "advance the PC" code -- why is that ok?
>>>>>
>>>> I also dropped the immediately following goto statement. With these
>>>> changes PC is advanced in the same way as it happens during normal
>>>> translation. That is because we actually have to do the instruction
>>>> translation process here to support the case when a breakpoint with
>>>> matching PC is architecturally mismatched. As I understand, that
>>>> "advance the PC" code was necessary to produce a TB with non-zero size
>>>> so that it can be invalidated later when we clear the breakpoint.
>>> OK, that makes sense for the BP_CPU case but you still have the
>>> "goto done_generating;" in the else clause...
>>>
>>> Also, should we maybe make this TB be only one insn long even for
>>> the BP_CPU case? It seems like in the common case we will only
>>> execute one insn.
>>>
>> Right, I have to fix this PC advancement. But I can't think of why we
>> will only execute one insn...
> Well, typically we'll take the BP exception in the helper function.
> There's nothing inherently wrong with translating further code
> after this insn, but it's usually not going to be executed, so
> we might as well end the TB early.
>

Thank, it is clear now. What about getting rid of "goto done generating"
and always translate one insn to update PC accordingly? Sometimes in_asm
log complains about that when disassembler and translator disagree about
the instruction size.

Best,
Sergey

  reply	other threads:[~2015-09-18 17:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14 10:51 [Qemu-devel] [PATCH] target-arm: fix CPU breakpoint handling Sergey Fedorov
2015-09-18 13:50 ` Peter Maydell
2015-09-18 14:07   ` Sergey Fedorov
2015-09-18 14:14     ` Peter Maydell
2015-09-18 16:33       ` Sergey Fedorov
2015-09-18 16:36         ` Peter Maydell
2015-09-18 17:14           ` Sergey Fedorov [this message]
2015-09-25 11:34     ` Sergey Fedorov
2015-09-25 11:42       ` Sergey Fedorov

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=55FC4662.60901@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.