oracle / dtrace-utils

DTrace-utils contains the DTrace port to Linux
Other
132 stars 19 forks source link

Missing translator for `pr_psargs` #79

Open thesamesam opened 4 weeks ago

thesamesam commented 4 weeks ago
$ dtrace -n 'proc:::exec-success { printf("%s\n", stringof(curpsinfo->pr_psargs)); }'
dtrace: invalid probe specifier proc:::exec-success { printf("%s\n", stringof(curpsinfo->pr_psargs)); }: in action list: translator does not define conversion for member: pr_psargs
kvanhees commented 4 weeks ago

The issue here is that the implementation for pr_psargs, pr_argc, pr_argv, and pr_envp used to depend on a DTrace support patch in the kernel to construct this data in a DTrace-specific struct linked from a task. Since we no longer require an invasive kernel patch to provide DTrace functionality, providing these translated members has turned out to be quite complex. It is on the TODO list.

To give some technical background... pr_argv and pr_envp were pointers to userspace addresses in the pre-Linux days whereas on Linux they are kernelspace addresses. That means that the typical usage in D scripts based on copyinstr(curpsinfo->pr_argv[0]) is no longer going to work right. The pre-BPF version included a hack to "fake" copyin*() operations on these pointers, instead accessing kernel memory directly when the given address referred to a pointer in the pr_argv or pr_envp arrays.

We may have to give in here and declare that this is a minor incompatibility between earlier DTrace and the new version, given that the pointers in question are provided by the kernel and thus outside the control of DTrace on whether they are userspace or kernel space pointers.

thesamesam commented 4 weeks ago

Thanks for explaining. psinfo_t as a whole was completely new to me and I went through a rollercoaster of "oh, that's really cool", "wait, is it on Linux?", "no, of course it isn't...", then "wait, DTrace has translators?", then this :)

Is there an idiomatic way to get the same information now? Or do we need to e.g. store it on exec in probes? That's OK if so.

I'm interested in both:

For the latter, I did https://wiki.gentoo.org/wiki/DTrace#Investigating_locks (tl;dr: save across probes) and it worked fine, but I'm new to D so wondering if I did it in the best way.