Re: [PATCH v2 1/2] riscv: kprobes: simulate nop and c.nop instructions

[Nam Cao <namcao@linutronix.de>]

Xiaofeng Yuan <yuanxiaofeng@eswincomputing.com> writes:
> nop and c.nop have no architectural effect, so allocating an
> out-of-line instruction slot and single-stepping through them is
> pure overhead. Simulate them directly in the breakpoint handler
> by advancing the program counter, following the approach already
> used on arm64.

That is not the reason why arm64 simulate nop. And how is single
stepping slower than simulating?

> This avoids slot allocation, text patching, IRQ flag save/restore
> and the single-step exception for these instructions.
>
> riscv_probe_decode_insn() is shared by kprobes and uprobes, so the
> simulation also applies to uprobes placed on nop instructions. This
> is relevant for USDT probe sites in user-space binaries, which are
> nop/c.nop instructions, the same use case that motivated the arm64
> implementation.

I can only find https://github.com/chrisa/libusdt, which does not have
riscv support. Which USDT are you referring to?

> In kernel text, nops are also found at ftrace mcount call sites and
> disabled jump_label sites.

Not sure about mcount, but isn't installing kprobe on jump labels forbidden?

> Measured on QEMU (RISC-V virt, emulated), this reduces the per-hit
> cost of a kprobe on a nop by roughly 40% compared to single-stepping
> through the out-of-line slot.

Reading the arm64's commit, simulating nop should only improve uprobe,
not kprobe; or am I confused somewhere?

Nam

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