Re: [arm64, debug] PTRACE_SINGLESTEP does not single-step a valid instruction

From: Will Deacon <will@kernel.org>
To: Luis Machado <luis.machado@linaro.org>
Cc: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [arm64, debug] PTRACE_SINGLESTEP does not single-step a valid instruction
Date: Tue, 18 Feb 2020 08:44:00 +0000	[thread overview]
Message-ID: <20200218084359.GA16828@willie-the-truck> (raw)
In-Reply-To: <5028f457-5b7d-1a88-912f-3fa97b567985@linaro.org>

On Fri, Feb 14, 2020 at 12:45:31PM -0300, Luis Machado wrote:
> On 2/13/20 2:07 PM, Luis Machado wrote:
> > On 2/13/20 9:01 AM, Will Deacon wrote:
> > > Sorry for the very slow reply. I talked to Mark about this a bit but it
> > > seems that we never followed up here.
> > 
> > No worries.
> > 
> > > 
> > > On Tue, Dec 10, 2019 at 05:00:18PM -0300, Luis Machado wrote:
> > > > Do you have any input regarding this particular situation?
> > > > 
> > > > It would be nice to get this fixed before the release of another GDB
> > > > version, if the fix is to live in GDB itself.
> > > 
> > > Basically, I'm very nervous about fixing this in the kernel because
> > > whatever we do will be visible to userspace. On the other hand, this
> > > part of the ptrace interface is only seriously used by GDB and we should
> > > make sure that it works well.
> > > 
> > > Does the diff below solve the problem? If so, can you confirm that it
> > > doesn't appear to regress anything else for GDB?
> > 
> > Thanks for the patch. I'll exercise this in various ways to see if
> > anything breaks.
> > 
> 
> I gave this a try with the particular test in GDB's testsuite that exposed
> the problem. It is working as expected now, so we're single-stepping past
> the instruction correctly instead of getting a spurious SIGTRAP.
> 
> I managed to run a few other tests related to syscalls and signals and they
> also executed as expected. But this was inside QEMU.
> 
> Do you see any potential scenarios where this change may break things? Other
> things i should try to exercise?

Could you run the entire testsuite please and check there aren't any
regressions? Hardware would be best, but QEMU is still useful.

> Given we need to be careful with a kernel patch at this stage, i just want
> to make sure I covered all/most the possible cases.
> 
> Otherwise, I'm happy with this change. Thanks for putting it together!

I'll add your Tested-by, but I'd still like review from Mark.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel