[lttng-dev] Userspace Tracing and Backtraces

Brian Robbins brianrob at microsoft.com
Fri Mar 6 13:51:44 EST 2015

Thanks Francis.

Is it accurate to say then that the array of addresses would need to be captured by app code by writing a stack walker by hand or using the perf capture mechanism that you describe below?


From: Francis Giraldeau [mailto:francis.giraldeau at gmail.com]
Sent: Friday, March 6, 2015 7:13 AM
To: Brian Robbins; lttng-dev at lists.lttng.org
Subject: Re: [lttng-dev] Userspace Tracing and Backtraces

2015-03-05 17:39 GMT-05:00 Brian Robbins <brianrob at microsoft.com<mailto:brianrob at microsoft.com>>:

I’m looking into using the userspace tracing capabilities of LTTng, and I wanted to find out if it is possible to capture a stack backtrace when a userspace tracepoint is hit.

The simple way is to use a tracepoint, where there is an array of addresses. Symbols resolution can be done offline using the baddr events indicating the address of shared libraries, and using libdwarf to parse ELF.

To get the actual backtrace, you can use either frame pointers, but most linux distributions compiles with -fomit-frame-pointers, and then this method does not work (even of your own program is compiled with -fno-omit-frame-pointer, a shared library, like libc, without frame pointer in the middle of the stack does break the frame chain). Then, stack unwind (using libunwind for instance) is necessary.

It could be nice to add such feature an event context to lttng-ust, it would allow to record the ELF callstack for any userspace event. The question is whether doing the unwind online (but it is quite costly in time), or do it offline, like perf is doing, by recording 2 pages of the stack with registers (but records much more data, and may not work if there are large variables on the stack, and requires additional support for JIT code).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150306/44c536fe/attachment.html>

More information about the lttng-dev mailing list