[lttng-dev] Some questions about Lttng

Wed Jun 20 09:03:38 EDT 2012

* Zheng.Chang at emc.com (Zheng.Chang at emc.com) wrote:
> 
> > -----Original Message-----
> > From: Mathieu Desnoyers [mailto:mathieu.desnoyers at efficios.com] 
> > Sent: Wednesday, June 20, 2012 0:37 AM
> > To: Francis Giraldeau
> > Cc: lttng-dev at lists.lttng.org
> > Subject: Re: [lttng-dev] Some questions about Lttng
> 
> > * Francis Giraldeau (francis.giraldeau at gmail.com) wrote:
> > > Le 2012-06-19 05:50, Zheng.Chang at emc.com a écrit :
> > > >
> > > > Hi folks,
> > > >
> > > >  
> > > >
> > > > I'm studying how to use Lttng now. I built a kernel which version is
> > > > 2.6.38 and ran with lttng 2.0.
> > > >
> > > > I got some confused when I started to use it. Here are my questions:
> > > >
> > > >  
> > > >
> > > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel 3.x
> > > > support it already?
> > > >
> > > 
> > > You don't need a kernel patch with lttng 2.0, only modules are required.
> > > It uses the tracepoints already present in the kernel, and trace system
> > > calls, and uses perf performance counters and kprobes.
> > > 
> > > > 2. I tried to do something like, dump the arguments of system call, or
> > > > dump a backtrace in a specified function. But the output of lttng is
> > > > very limited. Is there a way to do that with lttng?
> > > >
> > > 
> > > If system calls are enabled, arguments are supposed to be dumped (option
> > > --syscall to lttng enable-event). If it's not the case, then are you
> > > sure you are using lttng 2.0 and not 0.12? ;) Because the older version
> > > has a different behavior. One additional note: few system calls do not
> > > have all their arguments decoded in lttng 2, but there are only a few.
> 
> > There is no backtrace dump feature in lttng 2.0.
> 
> > Arguments of system calls are almost all there on x86 32/64 and ARM.
> > What architecture are you using ?
> 
> 
> My tsetbed is x86 32bit and lttng's version is 2.0.1. You're right. I can see the arguments now.
> 
> 
> > > 
> > > > 3. I looked into some UST examples and found here are three header
> > > > files:  tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h.
> > > > They have some duplicated macro definitions like TRACEPOINT_EVENT.
> > > >
> > > 
> > > The macros are quite complicated. Some includes files are included more
> > > than once to generate various portion of the tracepoint code. So, my
> > > advice here is to take a working example and adapt it to your needs.
> 
> > Good advice.
> 
> > > 
> > > > And the examples includes all of these three header files despite no
> > > > conflict here. Could someone help to explain the intention?
> > > >
> > > > 4. Once I defined a tracepoint in my code, seems some initializations
> > > > would register default probe into the hook point.  How to disable the
> > > > default probe and  register my self-defined probes?
> > > >
> > > 
> > > You mean, call a custom function when tracepoint is executed? Maybe
> > > somebody else has an answer, but AFAIK this is not possible. But you
> > > could make a wrapper to your tracepoint and then call your additional
> > > function there.
> 
> > Yep, not possible. You'd have to wrap the tracepoint.
> 
> > > 
> > > > 5. Does lttng-ust support dynamic traceing like kprobe?
> > > >
> > > 
> > > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody
> > > else can confirm/infirm the dynamic tracepoint feature in user-space?
> 
> > This is correct.
> 
> > Thanks,
> 
> > Mathieu
> 
> > > 
> > > You can use a feature of GCC to regiter callback on function entry and
> > > exit, but since it executes for all functions, then the overhead is very
> > > high. You can have a look here:
> > > 
> > > https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c
> > > 
> > > Cheers,
> > > 
> > > Francis
> 
> 
> And here are some subsequent questions about lttng:
> 
> 6. Does lttng-ust support marker? Marker is easier to be compatible
> with the APIs like printf if we don't care its performance issue.

Not currently. We plan to implement a "tracepoint_printf" (or
trace_printf, not sure yet) that will behave similarly to the Linux
Kernel Markers (back in the early lttng 0.x days). This will definitely
fulfill your use-case, but it's just not there yet.

> 7. What's supposed to show with 'lttng list -u'? It's empty now. Is
> that possible to show the events defined in an application?

List of tracepoints in _currently running_ _registered_ applications
only. An application registers when linked with liblttng-ust.

> 8. What does disable-event command of lttng do? With the
> example(hello) provided by lttng-ust, I enabled all events with '-a
> -u' and then disabled them again.  I launched the example with gdb and
> dumped the tracepoint's structure and then found its state was active.
> It's supposed to be inactive here, right?

Can you provide the detail of commands you launched, and the result of
gdb printout ? Please run "hello" with LTTNG_UST_DEBUG=1 env. var set.

> BTW: I didn't see any trace generated here with view command.

That is after the disable, right ?

Also, did you do a lttng start at some point in your test ?

Thanks,

Mathieu

> 
> Thanks all for your useful info!
> 
> Best regards
> Zheng
> 
> > > _______________________________________________
> > > lttng-dev mailing list
> > > lttng-dev at lists.lttng.org
> > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> 
> > -- 
> > Mathieu Desnoyers
> > Operating System Efficiency R&D Consultant
> > EfficiOS Inc.
> > http://www.efficios.com
> 
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com