stapstd elf note flags

[Andrii Nakryiko]

On Mon, Jan 12, 2026 at 3:11 PM Frank Ch. Eigler <fche@redhat.com> wrote:
>
> Hi -
>
> > > Just one more bit of detail please: what NOP5 instruction is it that
> > > would require two interrupts through an older kernel?  There doesn't
> > > exist another 5-byte nop that (how much?) older kernels recognize as
> > > one instruction?
> >
> > Jiri is currently using:
> >
> > 0f 1f 44 00 00          nop    DWORD PTR [rax+rax*1+0x0]
> >
> > I don't think there is any 5-byte nop that would be handled by (older)
> > kernels without single-stepping.
>
> Note the question was *regression*, i.e., worse than the status quo on
> these old kernels.  AIUI, there's an int3 hit for each such uprobe
> anyway, so what I'm looking for is an explanation why there would be
> TWO if you switched the nop1 to any conceivable nop5.
>

Ok, I see what you are asking. For nop1, there is indeed one int3,
then kernel analyzes the instruction interrupted and sees that it's
one of the instructions that can be emulated without going back to
user space for single stepping. E.g., stack pushes are simulated like
that, for instance; and a bunch of other instructions as well. And for
such emulated instructions, we don't need single-stepping, so we avoid
another context switch and interrupt.

But nop5 is not like that, old kernel didn't recognize it as anything
special that the kernel can handle, so it falls back to
single-stepping, which is what adds extra overhead.

Hope that helps.

> > [...]
> > But please double check, I believe that logic is in
> > arch_uprobe_analyze_insn in arch/x86/kernel/uprobes.c
>
> Righto.
>
> > > (What kind/size of nop a NT_STAPSDT refers to is not actually limited
> > > by the spec.)
> >
> > but unfortunately the size of nop instruction(s) is also not recorded
> > anywhere, which is why we are in this predicament
>
> (Ideally, the size should not matter.)

But in this case, if we knew the size (1+5=6) we could safely assume
that nop5 was emitted through USDT macros. But oh well, we have to
find another way.

>
>
> - FChE
>