[PATCH v3 2/4] arm64: kgdb: disable interrupts while a software step is enabled

[AKASHI Takahiro]

Will,

Sorry for late response,

On Wed, Jun 07, 2017 at 05:50:18PM +0100, Will Deacon wrote:
> On Wed, Jun 07, 2017 at 02:34:50PM +0900, AKASHI Takahiro wrote:
> > On Mon, Jun 05, 2017 at 05:29:19PM +0100, Will Deacon wrote:
> > > On Tue, May 23, 2017 at 01:30:56PM +0900, AKASHI Takahiro wrote:
> > > > After entering kgdb mode, 'stepi' may unexpectedly breaks the execution
> > > > somewhere in el1_irq.
> > > > 
> > > > This happens because a debug exception is always enabled in el1_irq
> > > > due to the following commit merged in v3.16:
> > > >   commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
> > > > 			paths where possible")
> > > > A pending interrupt can be taken after kgdb has enabled a software step,
> > > > but before a debug exception is actually taken.
> > > > 
> > > > This patch enforces interrupts to be masked while single stepping.
> > > 
> > > The desired behaviour here boils down to whether or not KGDB expects to step
> > > into or over interrupts in response a stepi instruction. What do other
> > > architectures do?
> > 
> > I don't know x86 case, but if we step into interrupt code here,
> > doing stepi on a normal function will be almost useless as every
> > attempt of stepi will end up falling into irq code (mostly for timer
> > interrupt).
> > 
> > > What happens if the instruction being stepped faults?
> > 
> > Well, as a matter of fact, we get a gdb control somewhere in exception code
> > (actually just after 'enable_dbg' in el1_sync).
> 
> Ok, but don't we need to re-enable interrupts, otherwise we can't safely
> handle the fault (which might involve blocking)?

I thought a lot, but have got no other way to solve the issue, which
totally makes stepi in vain.
In theory, you might be right, but in practice, people don't always expect
to step through the whole sequence of fault recovery with single stepping.
Once we do 'c(ontinue),' interrupts are enabled again and the execution
will follow as expected.

If you want to 'step over' a faulted instruction here, or to break
somewhere in a middle of exception handler, you need to manage to set
a breakpoint explicitly. But it will, I believe, be much better than
useless stepi from day-1 :)

Meanwhile, kprobes also disables interrupts while single stepping.
See setup_singlestep().

Thanks,
-Takahiro AKASHI

> Will