Re: [DTrace-devel] [PATCH v2 0/4] ELF note-based USDT support

[Kris Van Hees <kris.van.hees@oracle.com>]

On Sun, Jun 08, 2025 at 02:42:04AM +0100, Sam James wrote:
> Alan Maguire via DTrace-devel <dtrace-devel@oss.oracle.com> writes:
> 
> > On 29/01/2025 15:33, Kris Van Hees wrote:
> >> Thank you for rebasing your work on the newest tree.  That will certainly
> >> help review them and move things forward.
> >> 
> >> I would definitely rework the commit message though, because
> >> 
> >> 1. DTrace has a specific understanding of what USDT probes are and how they
> >>    work and stap-based probes do not provide the same functionality.  One
> >>    example of that you already point ay: they are not discoverable - i.e.
> >>    they are not registered upon startup which is why you need to refer to
> >>    them directly by provider name (with embedded pid).  I think you need to
> >>    be very clear about the distinction.  Using STAPSDT or stapsdt might be
> >>    a better choice than referring to USDT.
> >>
> >
> > sure; I'll use stapsdt.
> >
> >> 2. I think that the commit message fails to highlight that this support is
> >>    to make it possible to trace programs (and shared librearies)that have been 
> >>    built with stap style probes.  I don't think it is in the best interest of
> >>    DTrace users to build their executables and shared libraries with stap
> >>    style probes over DTrace USDT probes, especially given the significant
> >>    advantage that DTrace USDT probes have (see 1. above).
> >> > 3. While I can see the point of mentioning how to add stapsdt probes to
> >>    code, it also is a source for confusion and thus is probably better left
> >>    out.  Since this is a compability feature, surely those wanting to use it
> >>    already have executables with such probes or know how to create them.
> >>    By including it here, you also introduce the very unfortunate fact that
> >>    stapsdt uses DTRACE_PROBE*() macros even though the probes have never really
> >>    been DTrace compatible, and it is only with your proposed patch now that
> >>    they could be used in DTrace.  The systemtap project shouldn't have
> >>    piggy-backed on DTRACE_PROBE*() in the first place because it causes this
> >>    type of confusion and complications, so I would very much prefer not to
> >>    highlight that mess with this patch series.
> >> 
> >> The stap probe support is very significant because we unfortunately do have to
> >> live with a world where there are multiple ways that such userspace probes
> >> have been implemented.  And given that packages are released with probes and
> >> people may want to trace them makes this addition certainly very worthwhile.
> >> But I think it should be clear that this is for compatibilty/interoperability
> >> purposes only.
> >> 
> >
> > Sounds good, I'll rework the patches accordingly.
> 
> Any update on this? I'd really love to start wiring up support for these
> in packages. I guess it interacts heavily with the work Kris has been
> doing on making LTO work with USDT though?

Yes, the USDT rework I actually just completed is a pre-condition of getting
support for stapsdt probes in DTrace.  With the new USDT approach in place,
this series can be revisited and adjusted to make use of what I introduced.

	Kris