stapstd elf note flags

[Andrii Nakryiko]

On Mon, Jan 12, 2026 at 4:23 PM Frank Ch. Eigler <fche@redhat.com> wrote:
>
> Hi -
>
> > 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.
>
> Oh, right.  I've been out of kprobes/uprobes land too long to recall
> this part.
>
>
> > [...]
> > 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.
>
> OK just spitballing here, but what if we emitted two adjacent notes,
> one for the nop1 and one for the nop5.  But mess with the
> name/provider strings of the second one a bit, so an old-school
> systemtap or stapbpf or whatever program would fail to match the
> second one.  Newer tools could identify the adjacency and relationship
> of the pair, and merge their semantics (place the probe on top of the
> nop5 only).
>

Sounds messy and complicated, tbh. Have you seen my reply to Nick up
the thread? That extra space after args string sounds like the least
intrusive way, tbh (and it's extensible if we take care to do it
properly from the start), but readelf returning error is a bit
off-putting. So I wonder if the right way is to just teach readelf to
not complain about extra information after args string in USDT note?
(We can try to design something that would be structured and
extensible upfront, so we don't have to go through this process again)

> - FChE
>