stapstd elf note flags

[Andrii Nakryiko]

On Mon, Jan 12, 2026 at 10:36 AM Frank Ch. Eigler <fche@redhat.com> wrote:
>
> Hi, Jiri -
>
>
> > [...]
> > That works well for apps running on new kernel that allows to optimize
> > nop5, but it will regress on old kernel, which needs to do single
> > stepping of the nop5 instruction when the USDT probe is hit.
>
> Can you explain the regression exactly?  Would and old kernel tripping
> across a nop5 cause more single-stepping ops than if it had come
> across a nop1?  Is that a big problem?

Yes, it takes one extra userspace->kernel->userspace trip (through
interrupt), which basically slows USDTs 2x, so that's not good
(especially that one of the main concern with uprobes and USDTs are
that they are relatively slow compared to kernel-side tracepoints).

>
>
> > To prevent that we would like to emit <nop1,nop5> instructions combo
> > for the USDT probe and install uprobe on top:
> >    - nop1 if kernel does NOT have nop5 optimization support
> >    - nop5 if kernel has nop5 optimization support
>
> Is this suggesting instrumenting the binary with a nop1 xor a nop5,
> based on whether the build-time kernel supports a particular facility?
> If so, that's unusual - in our distro building processes, build-host
> kernels are often rather older than the resulting distro kernels
> themselves.

No, we'll emit both nop1 first (for "legacy" implementations that are
not aware of nop5, they will just point to nop1), and right after that
nop5. And then updated library/tooling will need to recognize this
nop1+nop5 combo, and they will be able to install uprobe on top of
nop5 by adjusting USDT target address by +1.

And the thing here is how to signal that nop5 following nop1 belongs
to USDT and thus can be thought of as an atomic code block that no
other code should be jumping into the middle of. Because, in theory,
someone could have put nop5 right after USDT, and have some code that
jumps back into nop5 directly, bypassing nop1. If in such a case USDT
is attached at nop5 that would be wrong because nop5 is triggered more
frequently than intended USDT.

Hope that makes sense...

>
>
> > And to recognize such probes, we would like to mark USDT stapstd ELF
> > note with some flag saying this probe emits <nop1,nop5> instructions
> > combo.
>
> What would an old kernel or userspace do with such a distinct note type?
>

Yeah, that's my concern. You'd need updated libraries and tools to
take advantage of that, as I replied to Nick earlier. I don't like
this solution as it breaks compatibility and requires updating
everything.

>
> - FChE
>