[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UNEwP2FLOxW-OBJ0cQq9D+wr3AAERsOXBu-W7P6tYocQ@mail.gmail.com>
Date: Fri, 8 Jul 2022 09:44:07 -0700
From: Doug Anderson <dianders@...omium.org>
To: Will Deacon <will@...nel.org>
Cc: Sumit Garg <sumit.garg@...aro.org>,
Daniel Thompson <daniel.thompson@...aro.org>,
Wei Li <liwei391@...wei.com>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jason Wessel <jason.wessel@...driver.com>,
Marc Zyngier <maz@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/2] arm64: Fix pending single-step debugging issues
Hi,
On Fri, Jul 8, 2022 at 9:31 AM Will Deacon <will@...nel.org> wrote:
>
> On Fri, Jul 01, 2022 at 03:14:16PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, May 10, 2022 at 11:05 PM Sumit Garg <sumit.garg@...aro.org> wrote:
> > >
> > > This patch-set reworks pending fixes from Wei's series [1] to make
> > > single-step debugging via kgdb/kdb on arm64 work as expected. There was
> > > a prior discussion on ML [2] regarding if we should keep the interrupts
> > > enabled during single-stepping. So patch #1 follows suggestion from Will
> > > [3] to not disable interrupts during single stepping but rather skip
> > > single stepping within interrupt handler.
> > >
> > > [1] https://lore.kernel.org/all/20200509214159.19680-1-liwei391@huawei.com/
> > > [2] https://lore.kernel.org/all/CAD=FV=Voyfq3Qz0T3RY+aYWYJ0utdH=P_AweB=13rcV8GDBeyQ@mail.gmail.com/
> > > [3] https://lore.kernel.org/all/20200626095551.GA9312@willie-the-truck/
> > >
> > > Changes in v3:
> > > - Reword commit descriptions as per Daniel's suggestions.
> > >
> > > Changes in v2:
> > > - Replace patch #1 to rather follow Will's suggestion.
> > >
> > > Sumit Garg (2):
> > > arm64: entry: Skip single stepping into interrupt handlers
> > > arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step
> > >
> > > arch/arm64/include/asm/debug-monitors.h | 1 +
> > > arch/arm64/kernel/debug-monitors.c | 5 +++++
> > > arch/arm64/kernel/entry-common.c | 18 +++++++++++++++++-
> > > arch/arm64/kernel/kgdb.c | 2 ++
> > > 4 files changed, 25 insertions(+), 1 deletion(-)
> >
> > Sorry it took so long for me to respond. I kept dreaming that I'd find
> > the time to really dig deep into this to understand it fully and I'm
> > finally giving up on it. I'm going to hope that Will and/or Catalin
> > knows this area of the code well and can give it a good review. If not
> > then I'll strive harder to make the time...
>
> So the good news is that I spent a couple of days on this last week.
Excellent, thanks!
> The bad news is that I'm nowhere done and about to disappear on holiday
> for a week!
No worries. It's been broken for so many years and isn't the most
urgent thing, but it's also one of those things that I do eventually
want to get fixed so I just want to make sure it doesn't get put off
indefinitely...
> But anyway, I might be able to give this a review when I'm back. Failing
> that, I wonder if enough of us have a little bit of time each that we
> could hack on an agreed design together which covers the debug exception
> behaviour beyond kgdb?
If it will unblock this then I can figure out how to make time for it.
Definitely my biggest utility would be in testing, but I'm also happy
to knock around ideas. ...and as per above if the way to move forward
is to block off a day or two to learn more about all the status bits
and how they interact in the kernel then I can do that too. Barring
unforeseen circumstances I'll also be in Dublin in September if that's
somehow useful. ;-)
-Doug
Powered by blists - more mailing lists