[DTrace-devel] [PATCH v2 0/6] stapsdt provider: simple system-wide probing
Alan Maguire
alan.maguire at oracle.com
Wed Jan 7 12:47:56 UTC 2026
On 05/01/2026 12:27, 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 1 describes the approach; to facilitate systemwide tracing
> we need to tell DTrace the name of the binary/library via the
> module field in the probe specifier; 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.
> Full path specification in module name is not supported since
> DTrace does not allow a '/' in a module name.
>
I won't spam the list with another series yet, but it turns out
allowing '/' in probemod names - and thus supporting absolute paths -
is straightforward enough. I think there is also value in having path
expansion as it leads to more portable scripts that do not depend on
the precise (often distro-specific) location of a library, but it is
good to support both approaches I think.
One nice feature is we can get info about stapsdt probes in an object
using 'dtrace -lm':
$ dtrace -lm python*:/usr/lib64/libpython3.6m.so
ID PROVIDER MODULE FUNCTION NAME
6730 python* /usr/lib64/libpython3.6m.so line
6728 python* /usr/lib64/libpython3.6m.so function-entry
6726 python* /usr/lib64/libpython3.6m.so function-return
6724 python* /usr/lib64/libpython3.6m.so gc-start
6722 python* /usr/lib64/libpython3.6m.so gc-done
More information about the DTrace-devel
mailing list