Messages in this thread | | | From | Ganesan Rajagopal <> | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 | Date | Sun, 17 Sep 2006 10:24:23 +0530 |
| |
>>>>> Karim Yaghmour <karim@opersys.com> writes:
> And I submit to you an idea which I submitted to Ingo yesterday and have > not yet received feedback on. Here's static markup as it could be > implemented: > > The plain function: > int global_function(int arg1, int arg2, int arg3) > { > ... [lots of code] ... > > x = func2(); > > ... [lots of code] ... > } > > The function with static markup: > int global_function(int arg1, int arg2, int arg3) > { > ... [lots of code] ... > > x = func2(); /*T* @here:arg1,arg2,arg3 */ > > ... [lots of code] ... > } > > The semantics are primitive at this stage, and they could definitely > benefit from lkml input, but essentially we have a build-time parser > that goes around the code and automagically does one of two things: > a) create information for binary editors to use > b) generate an alternative C file (foo-trace.c) with inlined static > function calls.
This makes sense to me, when combined with kprobes. I refer to the dtrace Usenix http://www.sun.com/bigadmin/content/dtrace/dtrace_usenix.pdf. They argue (Section 4.2 Statically-defined Tracing):
"While FBT (Function Boundary Tracing) allows for comprehensive probe coverage, one must be familar with the kernel implementation to use it effectively. To have probes with semantic meaning, one must allow probes to be statically declared in the implementation. The mechanism for implemting this is typically a macro that expands to a conditional call into a tracing framework if tracing is enabled. While the probe effect of this mechanism is small, it is observable: even when disabled, the expanded macro introduces a load, a compare and a taken branch.
In keeping with our philosophy of zero probe effect when disabled, we have implemnted a statically defined tracing (SDT) provider by defining a C macro that expands to a call to a non-existent function with a well-defined prefix ("__dtrace_probe_"). When the kernel linker sees a relocation against a function with this prefix, it replaces the call instruction with a no-operation and records the full name of the bogus function along with the location of the call site. Wehn the SDT provider loads, it queries the auxiliary structure and creates a probe with a name specified by the function name. When a SDT probe is enabled, teh no-operation at the call site is patched to be a call into an SDT-controlled trampoline that transfers control into DTrace."
-- Ganesan Rajagopal
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |