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

[Alan Maguire]

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

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

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.

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