[DTrace-devel] [PATCH v3 0/9] stapsdt provider: simple system-wide probing

[Kris Van Hees]

On Fri, Jan 16, 2026 at 03:10:52PM +0000, Alan Maguire wrote:
> On 16/01/2026 14:48, Kris Van Hees wrote:
> > 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?
> >
> 
> Yep; this works, along with tracing of existing processes for the traced
> object. See the documentation patch for an example of doing
> this with python. The example will trace python probes in python processes
> that were started either before or after tracing has begun.
>  
> > 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.
> > 
> 
> That's more an issue with the tests than the functionality itself. I can
> expand the tests to more fully demonstrate this. It's just easier in
> practice to invoke the associated command with 'dtrace -c'.

OK, but without tests that actually exercise the functionality, there is no
good way to verify that the implementation does the right thing, and that it
will keep doing that (i.e. detect any regressions).  Without tests that
exercise the functionality, we cannot review and merge the patch series.

> > 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?
> >
> 
> The tests demonstrate the case where we start system-wide tracing
> before starting the program we want to trace. In that case 
> systemwide tracing adds the value that we don't need to trace
> a specific process in advance; any process that has the probes
> will trigger firing.  For example, a user wants that functionality to
> trace probes in future QEMU processes regardless of pid, so that's 
> definitely something folks want.

Actually, that is not true.  Since the tests in the series all use dtrace -c,
the process is started prior to resolving the probe specifications as part of
the D script compilation.  So, they do not exercise the case of starting
tracing prior to starting the program at all.

> The documentation patch demonstrates the case where we want to trace
> an already running program/library; in that case I started tracing
> python3 probes and captured (already running) tuned-related events.
> 
> Both are valuable I think, and the combination of both is too; i.e.
> regardless of when a process started (whether prior to starting
> tracing or afterwards) I want to see events.

Oh, I certainly agree that this is the functionality we want.  I am just saying
that the tests in the series do not in any way exercise that functionality, so
there is no testsuite verification that any of this actually works and that if
a regression were to occur, that there would be tests that show that.

So, we definitely need tests in this series that show:

1. show it works for executables and libraries with -c (you already have those)
2. show it works for executables and libraries with a program that was started
   before dtrace
3. show it works for executables and libraries with a program that was started
   before dtrace AND for a second program that was started after dtrace
4. show it works for executables and libraries with two or more programs that
   get started after dtrace

(I think those are all the cases one would expect to work)

> > 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
> >>
>