Co-oridnate system for adding probes

[Vara Prasad <prasadav at us dot ibm dot com>]

Hi,

   Here is the initial list of coordinates that we can use to define 
probe points

Code or Program counter based
1) Entry: We already have code for this and the need is obvious.
2) Exit: Prototype code is out and the need is obvious.
3) At the label: Kernel has goto labels in many functions to jump out
   for error handling and other needs. This probe instruction will be 
the first instruction
   to get executed once the label is reached.
4) Insert a probe at a line number in the file or function + offset. As 
you can see both
   of these are not very portable from one version to other and 
platform to platform.
5) Insert a probe before calling a specified function. If there are 
multiple calls to the
   specified function default is to put the probe before the first 
call.  I would like to clarify
   this a bit. For example in the following code
    line#   
    99       a=bar(x,y)
   100      if  (foo (a, max (b,c), min (c,d))
    101         z=10;  
   
   if probe specifies that we should add a probe before calling 
function min().
   It means we need to add the probe before executing line 100 entirely.
   In other words this is a more reliable and portable way of 
specifying  a line
   of code where we should put a probe then the line number.
6) After returning from a specified function call. This is potentially 
not a
   good one to implement because of branching after the call. In other 
words
   if we have code like the following
   if  (foo())
      .....
   else
      ....
   we have to add probe in both parts of the if, which we may or may 
not be able
    to do it correctly due to compiler optimizations.
7)  At the beginning of a function only if that function is called from 
a specified function.
    In this case we could make generic kprobe handler to check for the 
calling function
    address and call the registered probe only if the calling function 
matches to the
    specified one otherwise continue as if nothing happened. This still 
has the performance
    penalty of hitting a trap if the calee is not the required one.

Event  based

1) When a particular event like timer or page fault  etc. occurs.
2) A particular memory location is accessed using watch point mechanism.
This mechanism is limited to number of debug registers but extensible using
software although performance of such an extension needs to be studied.
3 )Exceeding a set resource limit. For example asking for memory more than
a given size, high water marks as Brad mentioned etc.

Static Trace points
If we can do most of the above then we will be able to get a much better 
view
of the system then we can today, however we may not be able to reach all
the places of the code that we need. We might be able to convince kernel
community for a limited set of static trace points after we show the value
of the tool using the above dynamic methods. I have also seen some evidence
from the community to accept limited NO OP markers in the mailing list, but
i think we have to first show our value using dynamic methods.

1) A simple NO OP marker with a good comment so people don't remove it.
2)  Real trace function call in the code itself. This is bit more 
controversial
with the community, we should consider this as the last resort.

This is just a start before i get way behind. I am sure there are other 
methods i have not
covered. After we agree upon which of the co-ordinate systems make sense 
then
we can work on ways to specify them in the language.

bye,
Vara Prasad