Re: [Qemu-devel] [lttng-dev] [RFC PATCH v2 0/4] simpletrace : support var num of args and strings.

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

Hi Stefan,

* Stefan Hajnoczi (stefanha@gmail.com) wrote:
> On Tue, Jan 10, 2012 at 12:14 AM, Mathieu Desnoyers
> <mathieu.desnoyers@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