Re: design: function-exit probes

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Fri, 2005-03-11 at 01:19, Richard J Moore wrote:
> 
> 
> Some points on reading your document:
> 
> 1) why vote for having the return probe removal imply the probe removal.
> Surely it should be the other way round.

It is the other way around.  We just enhanced unregister_kprobe and
unregister_jprobe to also unregister the associated rprobe, if any.

> 2) is there a technical reason for enforcing removal of the trampoline
> probe when the entry probe is removed? If not then I wouldn't impose this
> restriction. Similarly vice versa if trampoline removal doesn't necessitate
> probe removal.

Once installed, the probe at the trampoline stays there forever, and is
"real" probepoint for all function returns.  I assume you're talking
about the rprobe here.

We could add support for registering and unregistering an rprobe
independent of the corresponding kprobe/jprobe.  No big deal if people
find it worthwhile.  It would require us to create "implicit" kprobes
for rprobes without explicit associated entry probes.  And we'd have to
add more calls to the API (register_rprobe, unregister_rprobe,
unregister_erprobe, unregister_jrprobe).  We definitely need to retain
the ability to register (or unregister) the entry and exit probes at the
same time.  

> 3) the alternate implementation of placing a probe on the RA doesn't imply
> the possibility of spurious hits as long at the probe is activated only
> when the called function is entered.

Because of SMP issues, I'd expect us to have to leave the int3 at the RA
in place all the time, and decide based on stack pointer (thread ID
wouldn't be sufficient) whether a particular int3 trap is associated
with a function return.

> 4) I agree that some automatic actions will be needed. For example when a
> called routine exits then the return probe will need to be removed
> especially if it's implemented by altering the RA on the stack.

I don't think I understand this point.  In the current implementation,
we don't need to remove a probe when a probed function returns.  We just
recycle the associated rprobe_instance (which maps stack pointer to
rprobe).

> 5) How are you going to handle multi-level returns? If you don't you'll
> leak memory associated with the trampoline.

Here I assume you're talking about something, akin to a longjmp, that
bypasses one or more returns.  Yeah, we'd leak rprobe_instance objects
any time the number of entries to a function is greater than the number
of associated returns.  Anybody know under what circumstances that sort
of thing happens?

Seems like do_execve() and do_exit() would dismantle a task's stack.  So
we should add code to them to clean up the that tasks's
rprobe_instances, right?

> 6) How will this work in a consistent way where the RA is stored in a
> register e.g. zSeries and RISC architectures?

I've looked at ppc64, and it looks to me like it'll work there.  We just
adjust the RA in the saved LR register (instead of atop the stack) upon
entry to the function.  See my post "function-exit probes += ppc64" on
2/18/05.

I haven't looked at zSeries.

> 7) You don't get the coat-tailing problem with your approach but what about
> dynamic return address generation? Not unreasonable where return and
> decision logic (e.g based on success) is combined.

I'd need to know more about this to comment.  If the RA changes during
execution of the function, we're toast.  But under what circumstances
does that happen?

> 
> - -
> Richard J Moore
> IBM Advanced Linux Response Team - Linux Technology Centre
> MOBEX: 264807; Mobile (+44) (0)7739-875237
> Office: (+44) (0)1962-817072

Jim