Hi Stefan, * Stefan Hajnoczi (stefa...@gmail.com) wrote: > On Tue, Jan 10, 2012 at 12:14 AM, Mathieu Desnoyers > <mathieu.desnoy...@efficios.com> wrote: > > This is needed to (very soon) add support for sdt.h in LTTng-UST 2.0, so > > systemtap and gdb can hook into tracepoints declared by lttng-ust 2.0. > > If lttng supports sdt.h in the future will it also provide a dtrace(1) > wrapper? I'm wondering if we can boil it down to the common DTrace > code that we already use in QEMU for SystemTap and that the > SmartOS/Illumos folks have used with DTrace.
What we plan to provide is the other way around: because we want to keep the TRACEPOINT_EVENT description, which specify the mapping between the arguments passed to the tracepoint() and what is to be serialized into the trace, as part of the application code, we require that the instrumentation be specified in the form of TRACEPOINT_EVENT and called with tracepoint(). The bonus here is that the tracepoint() macro can embed a STAP_PROBEV() call, which should be compatible with systemtap and gdb. Another point worth noting is that sdt provider uses a breakpoint to call the probes from the application instrumentation sites, which brings an added overhead compared to tracepoints when it is activated. This is another reason for staying with tracepoints and not use SDT as is within lttng-ust. One more point is that tracepoints put all side-effects of the parameters passed to the tracepoint() macro inside the "instrumentation enabled" code path (pointer dereferenced, offsets computation, functions called...). Therefore, when tracepoints are disabled, they just cost a branch (which we plan to optimize to a no-op, as permitted by gcc asm goto). In theory, it might not be impossible to create a translator from a subset of the dtrace language to TRACEPOINT_EVENT declarations. It is just not on our roadmap at this point, and I'm not sure it's worth the effort, when a simple script could translate from qemu-kvm trace-event file to TRACEPOINT_EVENT declarations. Thoughts ? Best regards, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
