Re: [PATCH v2 0/6] stapsdt provider: simple system-wide probing
Alan Maguire <[email protected]> Wed, 7 Jan 2026 12:47:56 +0000
| Newsgroups | dev.linux.lists.dtrace |
|---|---|
| Message-ID | <[email protected]> |
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