This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

function tracing


Hi -

One possibility to perform the sort of function tracing discussed
during the call is using a syntax like this:

probe kernel.function("something").callees {
  printk ($function . " entry");
}
probe kernel.function("something").callees.return {
  printk ($function . " exit");
}

The blocks of code within the probes would of course have to be
generic to any of the callee functions, so cannot be specialized
e.g. to the variables available in just one.

Within the translator, the probe construct could map to a list of
(kprobe-based) probes, one per function statically known to be
callable from "something()".  Perhaps the "callees" part could be
parametrized with a number to indicate desired nesting depth in the
static call graph, or even with "*" for "infinity".

Since these subsidiary probes would trigger even if some other
function was the caller, the probe body would probably be
synthetically prefixed with a check like

  if ($caller != "something") return;

(This prefixed check would get more elaborate for nesting depth > 1
to account for the non-treeness of the call graph.)

A similar concept might apply to the dual situation: referring to the
*callers* of a given function as a group.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]