[PATCH v2 1/2] riscv: kprobes: simulate nop and c.nop instructions
Nam Cao
namcao at linutronix.de
Wed Aug 26 06:04:26 PDT 2026
Xiaofeng Yuan <yuanxiaofeng at 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
More information about the linux-riscv
mailing list