stapstd elf note flags

[Andrii Nakryiko]

On Mon, Jan 12, 2026 at 5:02 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Jiri,
>

Hi Nick,

I'm working with Jiri on making this new nop5-based USDT speed up
practical and transparent. I'm also author of
https://github.com/libbpf/usdt/ so I have vested interest here :).
Please see my comments below.

> > We failed to squeeze/hack it in the current stapstd format.
>
> I take it that you cannot just have a new argument type using a non-power-of-2
> argument size ?  eg "5@nop" ?
>

There are basically few constraints that we are operating within. We'd
like to keep all existing USDTs working with all existing tooling, and
newly added USDT that would take advantage of nop5 to keep working
with existing tooling as well; as such, changing arguments format in
some incompatible way is undesirable. Having 5@nop would definitely
break bpftrace, for instance.

And because of the desire for backward and forward compatibility,
using new NT_STAPSDT + 1 is also undesirable, because that
automatically rules out all the existing tooling. Even if
tools/libraries are adapted to support both NT_STAPSDT and
NT_STAPSDT+1 USDT format, previously released version won't recognize
them.


So one thing that we attempted was to extend existing format in subtle
and backwards compat way: we added an extra zero after arguments
string. We can thing about this as one extra empty string after USDT
category, name, args strings. USDT note has overall data size stored,
and that one will include this zero.

This looks like it would work for all USDT-supporting tooling. The
relatively minor (but annoying) problem Jiri ran into is that when we
have extra bytes after args string, readelf would actually report that
as a warning and will return non-zero exit code. It still will show
all the data, but error code is a bit concerning.

But other than that, this seems like a promising approach. We can
define this post-args block either as string (so we can eventually
extend this to non-empty string), or maybe we should right away define
it as binary-based extra USDT info, which for now will have just a
flag that this USDT has nop1+nop5 optimization, but in the future can
be extended for anything extra (who knows, maybe some day we'll
include USDT arg names for more self-descriptive USDTs?).

So one question is how bad would it be to adjust readelf to not warn
about those extra bytes, but maybe just report them in hex (or
something along those lines)? Any opinions?

>
> > Do we need
> > to define new note type (like NT_STAPSDT + 1) for that, or is there
> > another way?
>
> Sticking with ELF notes is probably the best way forward.  At least in
> my opinion.  So if you do need a new note type then using NT_STAPSDT + 1
> would make the most sense.
>
> Cheers
>    Nick
>