This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes
- From: Andrew Morton <akpm at linux-foundation dot org>
- To: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Cc: Peter Zijlstra <peterz at infradead dot org>, Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Linux-mm <linux-mm at kvack dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Christoph Hellwig <hch at infradead dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Andi Kleen <andi at firstfloor dot org>, Oleg Nesterov <oleg at redhat dot com>, Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>, Roland McGrath <roland at hack dot frob dot com>, SystemTap <systemtap at sources dot redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Date: Mon, 14 Mar 2011 16:30:28 -0700
- Subject: Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes
- References: <20110314133403.27435.7901.sendpatchset@localhost6.localdomain6>
On Mon, 14 Mar 2011 19:04:03 +0530
Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
> Advantages of uprobes over conventional debugging include:
>
> 1. Non-disruptive.
> Unlike current ptrace based mechanisms, uprobes tracing wouldnt
> involve signals, stopping threads and context switching between the
> tracer and tracee.
>
> 2. Much better handling of multithreaded programs because of XOL.
> Current ptrace based mechanisms use single stepping inline, i.e they
> copy back the original instruction on hitting a breakpoint. In such
> mechanisms tracers have to stop all the threads on a breakpoint hit or
> tracers will not be able to handle all hits to the location of
> interest. Uprobes uses execution out of line, where the instruction to
> be traced is analysed at the time of breakpoint insertion and a copy
> of instruction is stored at a different location. On breakpoint hit,
> uprobes jumps to that copied location and singlesteps the same
> instruction and does the necessary fixups post singlestepping.
>
> 3. Multiple tracers for an application.
> Multiple uprobes based tracer could work in unison to trace an
> application. There could one tracer that could be interested in
> generic events for a particular set of process. While there could be
> another tracer that is just interested in one specific event of a
> particular process thats part of the previous set of process.
>
> 4. Corelating events from kernels and userspace.
> Uprobes could be used with other tools like kprobes, tracepoints or as
> part of higher level tools like perf to give a consolidated set of
> events from kernel and userspace. In future we could look at a single
> backtrace showing application, library and kernel calls.
How do you envisage these features actually get used? For example,
will gdb be modified? Will other debuggers be modified or written?
IOW, I'm trying to get an understanding of how you expect this feature
will actually become useful to end users - the kernel patch is only
part of the story.