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

Alan Maguire alan.maguire at oracle.com
Thu Jan 30 11:12:56 UTC 2025


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.

Alan

> 	Kris
> 
> On Wed, Jan 29, 2025 at 02:55:18PM +0000, Alan Maguire wrote:
>> This series adds support (patch 1) for ELF-note defined USDT
>> probes in binaries and libraries; patches 2-4 add tests.
>>
>> Basic pid-specific USDT support is added; i.e. it is necessary
>> to specify the target pid in the provider name such as
>> "example1234" ; future work could add pid wildcarding.
>>
>> ELF note defined probes are defined by including sys/sdt.h
>> from the systemtap-sdt-devel package, and are defined in
>> C programs via
>>
>> DTRACE_PROBEn(provider, probe, [args...])
>>
>> See the tests for concrete examples.
>>
>> For python, go, etc, USDT probes can be added via libstapsdt [1]
>> and associated language-specific bindings.  This allows users
>> of those languages to add USDT probes too.  For example, the
>> following example program adds a "pythonapp" probe "firstProbe"
>> using the python-specific libstapsdt binding:
>>
>> #!/usr/bin/python3
>> from time import sleep
>> import stapsdt
>> provider = stapsdt.Provider("pythonapp")
>> probe = provider.add_probe(
>> "firstProbe", stapsdt.ArgTypes.uint64, stapsdt.ArgTypes.int32)
>> provider.load()
>> while True:
>>     print("Firing probe...")
>>     if probe.fire("My little probe", 42):
>>         print("Probe fired!")
>>     sleep(1)
>>
>> We can then trace this via dtrace:
>>
>> # dtrace -n 'pythonapp503211:::* { printf("args %s, %d\n", copyinstr(arg0), arg1); }'
>>
>> dtrace: description 'pythonapp503211:::* ' matched 1 probe
>> CPU     ID                    FUNCTION:NAME
>>   6 286628                      :firstProbe args My little probe, 42
>>
>> [1] https://github.com/linux-usdt/libstapsdt
>>
>> Alan Maguire (4):
>>   USDT: support ELF-note-defined probes
>>   selftests/usdt: add test for USDT note-defined probe firing, args
>>   selftests/usdt: add test for USDT notes in shared library
>>   selftests/usdt: add test covering different forms of USDT note args
>>
>>  include/dtrace/pid.h                      |  29 ++
>>  libdtrace/dt_cg.c                         |  47 ++
>>  libdtrace/dt_cg.h                         |   1 +
>>  libdtrace/dt_pid.c                        | 466 ++++++++++++++++++++
>>  libdtrace/dt_prov_uprobe.c                |  19 +-
>>  test/unittest/usdt/sdt_notes.h            | 504 ++++++++++++++++++++++
>>  test/unittest/usdt/tst.usdt-notes-args.r  |   2 +
>>  test/unittest/usdt/tst.usdt-notes-args.sh |  51 +++
>>  test/unittest/usdt/tst.usdt-notes-lib.r   |  14 +
>>  test/unittest/usdt/tst.usdt-notes-lib.sh  | 145 +++++++
>>  test/unittest/usdt/tst.usdt-notes.r       |  14 +
>>  test/unittest/usdt/tst.usdt-notes.sh      | 121 ++++++
>>  12 files changed, 1406 insertions(+), 7 deletions(-)
>>  create mode 100644 test/unittest/usdt/sdt_notes.h
>>  create mode 100644 test/unittest/usdt/tst.usdt-notes-args.r
>>  create mode 100755 test/unittest/usdt/tst.usdt-notes-args.sh
>>  create mode 100644 test/unittest/usdt/tst.usdt-notes-lib.r
>>  create mode 100755 test/unittest/usdt/tst.usdt-notes-lib.sh
>>  create mode 100644 test/unittest/usdt/tst.usdt-notes.r
>>  create mode 100755 test/unittest/usdt/tst.usdt-notes.sh
>>
>> -- 
>> 2.43.5
>>




More information about the DTrace-devel mailing list