I need a mechanism that will enable users to see parameter values at the return point of a probe. Frank had a nice (and straightforward) suggestion of altering the translator to emit two probe points for one return probe. The first probe point, at the entry to the function, would be invisible to the user, and would automagically copy all parameters into script level globals $g_parm1, $g_parm2,..., $g_parmN. The second probe would behave exactly as the return probe does now, executing the user defined handler. I think that this is a very practical, very doable solution. Of course there would be a slight performance hit because now there are 2 probes to every one return probe. It may be more appropriate to have a new .return variant that can be used only if this behavior is necessary. Another option is to teach the translator to take advantage of a few new variables defined in struct kretprobe & struct kretprobe_instance (see attached) that could store references to the params on entry to the function. see: attached patch see: http://sourceware.org/ml/systemtap/2005-q3/msg00593.html I am unsure of what exactly it would take for the translator to exploit this feature, however I suspect it is far more complicated than the first proposed solution. Not to mention that changes to kernel code (however small) should be avoided. Yet another solution would be to simply not support this at all. If a user really wanted to see parameter values at the return, they can write the code themselves. I do not like this idea. The purpose of a tapset is to make things as easy as possible for the user. This issue will not necessarily block tapset development, as I can continue writing code *as if* I had access to these parameters. However it will inhibit tapset testing. Thus I think we should agree on how this will be handled.
Created attachment 672 [details] This patch adds an additional function pointer to optionally fire at the entry to a function with a return probe on it.
I've added code in dwarf_var_expanding_copy_visitor::visit_target_symbol() to allow read parameter access in return probes. What really happens behind the scenes is a new function entry probe is generated that saves the target variables so that they can be accesssed in the return probe. Note that if the kernel function being probed is called recursively and return probes get missed, the parameters given to the return function could be from the wrong call instance.