[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