From: Will Deacon <will.deacon@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
"dsaxena@linaro.org" <dsaxena@linaro.org>,
"Vijaya.Kumar@caviumnetworks.com"
<Vijaya.Kumar@caviumnetworks.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] arm64: kgdb: fix single stepping
Date: Fri, 5 Sep 2014 11:00:02 +0100 [thread overview]
Message-ID: <20140905100002.GJ13515@arm.com> (raw)
In-Reply-To: <1409910463-30936-1-git-send-email-takahiro.akashi@linaro.org>
On Fri, Sep 05, 2014 at 10:47:43AM +0100, AKASHI Takahiro wrote:
> I tried to verify kgdb in vanilla kernel on fast model, but it seems that
> the single stepping with kgdb doesn't work correctly since its first
> appearance at v3.15.
>
> On v3.15, 'stepi' command after breaking the kernel at some breakpoint
> steps forward to the next instruction, but the succeeding 'stepi' never
> goes beyond that.
> On v3.16, 'stepi' moves forward to the second instruction just after call of
> do_debug_execption() in el1_dbg, and never goes beyond that. This variance
> of behavior seems to come in with the following patch in v3.16:
>
> commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
> paths where possible")
I don't think you should worry about this change -- from what you're saying,
the code has never worked.
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 5901480..a345973 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -87,6 +87,13 @@
> 9990:
> .endm
>
> + .macro enable_dbg_if_not_stepping, tmp
> + mrs \tmp, mdscr_el1
> + tbnz \tmp, #0, 9990f
> + enable_dbg
> +9990:
> + .endm
We really don't want to bring this back, as it makes KVM guests extremely
slow (the mdscr access traps to the hypervisor).
It sounds more to me like kgdb is expecting step to remain active, but
that's not the case unless you explicit rewind the state machine (like we do
for ptrace). Can you try issuing the call to set_regs_spsr_ss in
single_step_handler, even when the step hook claims to have handled the
exception?
Will
prev parent reply other threads:[~2014-09-05 10:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 9:47 [RFC] arm64: kgdb: fix single stepping AKASHI Takahiro
2014-09-05 10:00 ` Will Deacon [this message]
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=20140905100002.GJ13515@arm.com \
--to=will.deacon@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Vijaya.Kumar@caviumnetworks.com \
--cc=dsaxena@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=takahiro.akashi@linaro.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