RE: function-exit probes += ppc64

["Chen, Brad" <brad dot chen at intel dot com>]

Tail call removal doesn't only happen with recursion.
It's also common if you have a procedure that ends with
a call to another procedure that is called from only 
one location. In this case you have a call wihtout a
return as well as a return without a call.

The questions would be (a) what optimization level is
required to cause such optimizations to happen, and (b)
how do people build their kernels. I'll try to remember
to talk some compiler folks about this.

Brad 

-----Original Message-----
From: Jim Keniston [mailto:jkenisto@us.ibm.com] 
Sent: Thursday, February 24, 2005 5:21 PM
To: Chen, Brad
Cc: SystemTAP; Haren Myneni
Subject: RE: function-exit probes += ppc64

On Thu, 2005-02-24 at 09:15, Chen, Brad wrote:
> Can somebody in the know comment on the use of tail call
> removal and inlining in the kernel? Is it common or rare?
> If it is common, this approach won't work very well. It
> will certainly tend to become more common if kernel builds
> get more and more optimized over time.
> 

I don't think this is just a function-return issue.  My understanding is
that if a function return gets eliminated by tail-recursion-optimization
or inlining, then the function call will be eliminated as well. 
Counter-examples are welcome.

I can imagine that there are certain functions where the number of calls
doesn't match the number of returns (e.g., related to fork, exec,
exit).  We'd definitely need to be aware of those.

> Are there any analogs to setjmp/longjmp or exception
> handling that we would have to deal with? These use
> the return address in user level code but maybe they
> aren't problems in the kernel.
> 
> On missed kprobes (1.6.3) seems one useful option would
> be to printk the first instance, and then printk a summary
> when the probe is deregistered.

Yeah, something like that.  Maybe also report the 10th, 100th, and
1000th miss as well.  Maybe count "hits" as well as misses, too, to
report upon deregistration.

> Better than a printk would
> be to somehow direct this info back to stap.
> 
> I think the Itanium situation may be substantially messier 
> than the PPC but I'd rather not get into that yet...
> 
> Brad
> 
> -----Original Message-----
> From: systemtap-owner@sources.redhat.com
> [mailto:systemtap-owner@sources.redhat.com] On Behalf Of Jim Keniston
> Sent: Friday, February 18, 2005 4:27 PM
> To: SystemTAP
> Cc: Haren Myneni
> Subject: function-exit probes += ppc64
> 
> Here's the function-exit probes design, updated after a talk with
Haren
> about ppc64.  See Appendix A.  I'm no PowerPC expert, so if you are,
let
> me know if you see any problems.
> 
> Jim Keniston
> 
>