stapstd elf note flags

Nick Clifton nickc@redhat.com
Tue Jan 13 10:11:22 GMT 2026


Hi Andrii,

> 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?

Updating readelf would be a simple task.  It could report extraneous
bytes as a warning rather than an error and it could even be taught
about the trailing zero and its new meaning.  So if you decide to go
ahead with this change just let us know - or better yet, submit a
patch to readelf yourself.

Cheers
   Nick



More information about the Systemtap mailing list