On Tue, Mar 31, 2020 at 10:39:42AM +0800, tingwei@codeaurora.org wrote:

在 2020-03-30 21:42，Will Deacon 写道：

quoted

On Mon, Mar 30, 2020 at 01:39:46PM +0100, Mark Rutland wrote:

quoted

On Sat, Mar 28, 2020 at 04:32:09PM +0800, Tingwei Zhang wrote:

quoted

If external debugger sets a breakpoint for one Kernel function
when device is in bootloader mode and loads Kernel, this breakpoint
will be wiped out in hw_breakpoint_reset(). To fix this, check
MDSCR_EL1.HDE in hw_breakpoint_reset(). When MDSCR_EL1.HDE is
0b1, halting debug is enabled. Don't reset debug registers in this

case.

quoted

I don't think this is sufficient, because the kernel can still
subsequently mess with breakpoints, and the HW debugger might not be
attached at this point in time anyhow.

I reckon this should hang off the existing "nodebumon" command line
option, and we shouldn't use HW breakpoints at all when that is
passed.
Then you can pass that to prevent the kernel stomping on the external
debugger.

Will, thoughts?

I was going to suggest the same thing, although we will also need to
take
care to reset the registers if "nodebugmon" is toggled at runtime via
the
"debug_enabled" file in debugfs.

Thanks for the suggestion, Mark and Will. It's a great idea to use
"nodebugmon". When "nodebugmon" is set, Kernel won't change HW breakpoints.

For reset the registers after "debug_enabled" is toggled, I'm thinking if
we are adding unnecessary complexity here.If we take that approach, we will
hook "debug_enabled" interface and use smp_call_function_single() to call
hw_breakpoint_reset() on each CPU. Wait for all CPUs' execution done and
change "debug_enabled". External debugger would clear the breakpoints when
it detaches the device and restores its breakpoints when attaches the
device.
Assume debug_enabled is changed to one after external debugger detaches the
device. Debugger would already clear the breakpoint registers. If debgger is
still attached, there's nothing Kernel can do to stop it restores/programs
the breakpoint registers.

What do you think of this?

It's all a bit of a mess. Looking at it some more, why can't the external
debugger simply trap access to the debug registers using EDSCR.TDA? That
way, we don't have to change anything in the kernel.

Will

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