stapstd elf note flags

Jiri Olsa olsajiri@gmail.com
Tue Jan 13 19:18:16 GMT 2026


On Tue, Jan 13, 2026 at 10:11:22AM +0000, Nick Clifton wrote:
> 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.

hi,
sounds good, we'll put together the change and send it your way

thanks,
jirka


More information about the Systemtap mailing list