probefunc/probemod have had a funny history as to where they try to get function name strings from. The probe-point-parsing variant is depended upon from the para-callgraph* examples, and that part could be well enough unprivileged. Other usages dip into the equivalent symdata(), which is (rightfully?) privileged. We should not so intermingle these. We could deprecate the privileged parts of probefunc(), so that in 1.8+, unprivileged scripts can use it (for probe-point-parsing only, or some cleaner equivalent). Or we could write a new function to do only that, and adjust sample scripts.
Should we just recommend pn() and pp() which are unprivileged?
> Should we just recommend pn() and pp() which are unprivileged? Not so simple; for para-callgraph*, we don't want boilerplate substrings of the pp/pn(), just the plain function names.
Building on tapset improvements from PR6580, I implemented a preprocessor conditional of the form %( systemtap_privilege == "privileged" / "unprivileged" %? ... %: ... %). The probefunc() implementation now wraps all kernel-space retrieval code in such a conditional, eliding it when compiled with a lower privilege, while leaving the user-space code available. This allows unprivileged use of probefunc() handily, while retaining backwards compatibility with its kernel-space uses for privileged scripts (no deprecation/rewriting necessary). For instance, para-callgraph* and such can now be run in unprivileged mode, so long as the probe points they're handed are appropriate of course. It remains to document the new systemtap_privilege check in order to make it available and documented if we want to consider it for similar uses in the future. (i.e. for having a tapset function provide a subset of the normal functionality in unprivileged mode)