[DTrace-devel] [PATCH v3 0/9] stapsdt provider: simple system-wide probing
Kris Van Hees
kris.van.hees at oracle.com
Fri Jan 16 14:48:38 UTC 2026
I think I am missing something... IS it your intent that this patch provides
for full system-wide tracing with wildcard support, i.e. where you can use a
probe specification with wildcards that is not satisfied yet by any probes in
userspace processes, and as processes are started, dtrace would attach to the
probes and start tracing them?
I do not see how this patch series accomplishes that. If anything, the tests
are all using direct invocation of a single program being traced, so the probes
are guaranteed to be available (discoverable) at the time of D script
compilation. I do not see any test that ensures that a 2nd process with probes
that matches the probe specification would also be traced correctly. There is
also no test that demonstrates that starting dtrace with -Z (allowing probe
specifications that cannot be satisfied yet) and then starting a process with
matching stap probes in it results in being able to trace those probes.
So, I do think I am misunderstanding what this patch series is aiming to
accomplish, which is probably the reason I am having a heard time reviewing it.
ALl the tests in this series, as far as I can see, do not need wildcards at all
because you can simply write prov$target:... and it will trace the correct
process.
Can you elaborate on what this is intended to provide? Or if it is meant to
provide system-wide tracing with wildcard support, can you add tests that do
exercise that functionality and show it works?
On Tue, Jan 13, 2026 at 04:51:23PM +0000, Alan Maguire wrote:
> This series adds wildcard support to stapsdt probes to allow
> tracing system-wide; this has caveats due to the way the kernel
> implements probe addition. In essence, probes are added on a
> per-inode basis (actually in the VMA associated with the inode)
> so it is necessary to identify the file where probes are found.
> Probes will fire for existing and new processes (the RFC incorrectly
> said they will not work for existing binaries; they in fact do).
>
> Patch 2 describes the approach; to facilitate systemwide tracing
> we need to tell DTrace the name of the binary/library via either
> using module absolute path (patch 1 updates parsing to support use
> of a '/' in a module descriptor to faciliate this support) or an
> module name; to expand this we then use [LD_LIBRARY_]PATH
> to resolve the full path. ELF reading of the file and insertion
> of probes then proceeds in a similar manner to per-pid tracing.
>
> Patches 3-8 test various aspects of systemwide probes; basic
> binary support, library support, listing support and is-enabled
> probes support, and use of absolute paths.
>
> Patch 9 updates docs to describe stapsdt wildcard support.
>
> Changes since v2:
>
> - support absolute paths (patch 1, 2)
> - add tests for absolute paths (patch 4, 7)
> - document systemwide probe support for listing/using absolute
> paths (patch 9)
>
> Changes since RFC:
>
> - update documentation/commit messages to reflect that we also
> catch existing programs/libraries when probes are enabled
> - fixup provider name for wildcard probes to be 'provider*'
> rather than using the confusing 'provider-1' since the
> latter is the concatenation of probename and pid (-1 is
> used to connote all pids)
> - add test for is-enabled systemwide probes
>
> Alan Maguire (9):
> dt_lex: support '/' in probe descriptors
> stapsdt provider: support systemwide probing
> test: add systemwide stapsdt note test
> test: add systemwide stapsdt note test using absolute path
> test: add systemwide stapsdt note test for library
> stapsdt: add test for listing systemwide probes in object
> stapsdt: add test for listing systemwide probes in absolute path
> object
> stapsdt: add systemwide test for is-enabled probes
> documentation: update stapsdt docs to describe wildcard support
>
> .../reference/dtrace_providers_stapsdt.md | 54 +++++-
> libdtrace/dt_lex.l | 2 +-
> libdtrace/dt_pid.c | 177 ++++++++++++++----
> libdtrace/dt_prov_uprobe.c | 17 +-
> .../tst.stapsdt-notes-systemwide-abspath.r | 2 +
> .../tst.stapsdt-notes-systemwide-abspath.sh | 51 +++++
> .../tst.stapsdt-notes-systemwide-isenabled.r | 13 ++
> .../tst.stapsdt-notes-systemwide-isenabled.sh | 177 ++++++++++++++++++
> .../tst.stapsdt-notes-systemwide-l-abspath.sh | 48 +++++
> .../usdt/tst.stapsdt-notes-systemwide-l.sh | 48 +++++
> .../usdt/tst.stapsdt-notes-systemwide-lib.r | 14 ++
> .../usdt/tst.stapsdt-notes-systemwide-lib.sh | 142 ++++++++++++++
> ...tst.stapsdt-notes-systemwide-lv-abspath.sh | 48 +++++
> .../usdt/tst.stapsdt-notes-systemwide-lv.sh | 48 +++++
> .../usdt/tst.stapsdt-notes-systemwide.r | 2 +
> .../usdt/tst.stapsdt-notes-systemwide.sh | 51 +++++
> 16 files changed, 845 insertions(+), 49 deletions(-)
> create mode 100644 test/unittest/usdt/tst.stapsdt-notes-systemwide-abspath.r
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-abspath.sh
> create mode 100644 test/unittest/usdt/tst.stapsdt-notes-systemwide-isenabled.r
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-isenabled.sh
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-l-abspath.sh
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-l.sh
> create mode 100644 test/unittest/usdt/tst.stapsdt-notes-systemwide-lib.r
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-lib.sh
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-lv-abspath.sh
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide-lv.sh
> create mode 100644 test/unittest/usdt/tst.stapsdt-notes-systemwide.r
> create mode 100755 test/unittest/usdt/tst.stapsdt-notes-systemwide.sh
>
> --
> 2.43.5
>
More information about the DTrace-devel
mailing list