On Tue, Jan 10, 2012 at 5:29 PM, Mathieu Desnoyers
<mathieu.desnoy...@efficios.com> wrote:
> 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.
I see, thanks for explaining.
> 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).
SystemTap has a solution for this problem where you wrap the
tracepoint with a guard:
if (QEMU_FOO_ENABLED()) {
/* ...expensive stuff here... */
QEMU_FOO(a, b, c);
}
In QEMU we don't really make use of this but I've heard applications
with expensive tracepoint arguments use this.
> 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.
Okay, QEMU can continue to emit LTTng UST tracepoints. I thought you
were planning to make UST source-compatible with DTrace sdt.h, which
would be convenient for applications that are already DTrace
instrumented but want a fast shared-memory mechanism instead of
breakpoints - they could use ust-dtrace(1) instead of dtrace(1) and
magically work with UST. In QEMU's case it doesn't matter because
we're already geared towards multiple tracing backends.
Stefan
