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