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

[Sam James <sam@gentoo.org>]

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?

cheeers,
sam

>
> Alan
>
> [...]