Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing translator for pr_psargs #79

Open
thesamesam opened this issue Aug 19, 2024 · 2 comments
Open

Missing translator for pr_psargs #79

thesamesam opened this issue Aug 19, 2024 · 2 comments

Comments

@thesamesam
Copy link

$ 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
Copy link
Member

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
Copy link
Author

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:

  • argv, but also
  • mapping fds for a PID <-> file locations

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants