[DTrace-devel] [PATCH v2 0/4] ELF note-based USDT support
Sam James
sam at gentoo.org
Sun Jun 8 01:42:04 UTC 2025
Alan Maguire via DTrace-devel <dtrace-devel at 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?
cheeers,
sam
>
> Alan
>
> [...]
More information about the DTrace-devel
mailing list