Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This is implemented almost entirely along with the pid provider, which is reassuringly similar to how it was done in the in-kernel days. They're really very closely-related beasts, and the same uprobe-based code can handle both easily enough. To reflect this, dt_prov_pid.c is renamed to dt_prov_uprobe.c. This does several things that are sufficiently intertwined that putting them in one commit seems most readable: - implements USDT probe discovery, ripping out a lot of old ioctl stuff and obsolete code handling stuff like structure-copying thunks in the Solaris C library and a bunch of obsolete functions around DOF acquisition (keeping one which might well be revived in the next phase), and adding dt_pid_create_usdt_probes, which scans the systemwide uprobe list and creates DTrace-side USDT probes (and their associated underlying uprobe-based probes) for any that are relevant (see below), using an sscanf-based parser: the uprobe naming scheme was designed so that it works with the limitations of such parsers. Thanks to the %m conversion specifier there is no risk of buffer overrunning if the name components are unexpectedly long. Right now this can only create probes for specific processes (those named on the command line in probe names, as usual), but in future it'll grow the ability to make probes for everything dtprobed has spotted probes for. Because it is driven by the systemwide uprobe list, it can create probes for processes that started before DTrace did, just like the old in-kernel model. - rejigs the pid provider support in dt_prov_uprobe.c (formerly dt_prov_pid.c) to use the new uprobe_create mechanism to make pid probes, with names consistent with uprobes created by dtprobed for USDT probes; the uprobes have names like dt_pid/[pr]_$dev_$ino_$addr. USDT probes pass their name components down as encoded uprobe arguments, viz: p:dt_pid/dt_2d_231d_7fbe933165fd /tmp/runtest.17112/usdt-dlclose1.123064.9010/livelib.so:0x15fd Ptest_prov=\1 Mlivelib__2eso=\2 Fgo=\3 Ngo=\4 (The [PMFN] prefix is added and stripped off automatically by the name en/decoder, and makes sure that no two "args" have the same name, even if the probe component is the same, as above.) - provides provide_usdt_probe to be called at USDT probe discovery time to create USDT probes and their underlying uprobe-based probes. The creation of the underlying uprobe-based probes is split off into a new funtion create_underlying that is also used for pid probes. Probe naming is designed to ensure that USDT probes and pid probes that are created at the same offset are associated with the same underlying probe. The struct dt_uprobe attached to the underlying probe gains a device number (which it should always have had) and keeps track of the underlying uprobe name from create_uprobe or USDT probe discovery and remembers whether or not DTrace created it (if dtprobed created it, dtrace must not delete it). USDT probes can be associated with more than one underlying probe (if the probe appears repeatedly in a program). Repeated calls to provide_usdt_probe for the same probe description but with different offsets will cause the USDT probe to be chained into the appropriate underlying probes (creating them as needed). - enabling gets a little more complex. We intern both the overlying (pid and USDT) probe *and* the associated underlying probe in the enablings list (by getting ->enable for the pid/USDT probe to walk its list of underlying probes and enable all of them), and to also add itself to the enablings list. - Trampoline generation has to adapt to this, but also has to use a less kludgy way of figuring out the pids the trampoline applies to: rather than parsing the name apart on the spot, we ask dt_pid, which already has code to *properly* parse apart both pid and usdt names and extract the pid from them. - stack arg handling needs a bit of a tweak. USDT probes can take a set of arguments that and are implemented as a fake function call. The underlying uprobe is placed right after the argument setup and therefore should be retrieved without applying PT_REGS_ARGSTKBASE for platforms on which PT_REGS_ARGSTKBASE > 0. The underlying probe gets the PP_IS_FUNCALL flag set to indicate this. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
- Loading branch information
1 parent
a28e369
commit 95ac5e2