Re: [PATCH 2/5] x86/uprobes: implement x86 specificarch_uprobe_*_step

From: Oleg Nesterov
Date: Wed Aug 08 2012 - 09:13:06 EST


On 08/07, Sebastian Andrzej Siewior wrote:
>
> The arch specific implementation behaves like user_enable_single_step()
> except that it does not disable single stepping if it was already
> enabled. This allows the debugger to single step over an uprobe.
> The state of block stepping is not restored. It makes only sense
> together with TF and if that was enabled then the debugger is notified.

I'll try to read this series later, just one nit for now...

> +static int insn_changes_flags(struct arch_uprobe *auprobe)
> +{
> + /* popf reads flags from stack */
> + if (auprobe->insn[0] == 0x9d)
> + return 1;

Ah, somehow I didn't think about this before.

->insn[0] doesn't look right, we should skip the prefixes.

Srikar, could you help? Perhaps validate_insn_bits() paths can
detect "popf" and do auprobe->fixups |= UPROBE_FIX_TF ?

This way we also do not need the new member in utask.

> +void arch_uprobe_enable_step(struct arch_uprobe *auprobe)
> +{
> + struct uprobe_task *utask = current->utask;
> + struct arch_uprobe_task *autask = &utask->autask;
> +
> + autask->restore_flags = 0;
> + if (!test_tsk_thread_flag(current, TIF_SINGLESTEP) &&
> + !insn_changes_flags(auprobe))
> + autask->restore_flags |= UPROBE_CLEAR_TF;
> + /*
> + * The state of TIF_BLOCKSTEP is not saved. With the TF flag set we
> + * would to examine the opcode and the flags to make it right. Without
> + * TF block stepping makes no sense. Instead we wakeup the debugger via
> + * SIGTRAP in case TF was set. This has the side effect that the
> + * debugger gets woken up even if the opcode normally wouldn't do so.
> + */
> + user_enable_single_step(current);

OK, once we have set_task_blockstep() we can change this.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/