Messages in this thread | | | Date | Tue, 12 Jan 2010 05:54:56 +0100 | From | Frederic Weisbecker <> | Subject | Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes |
| |
On Mon, Jan 11, 2010 at 05:56:08PM +0530, Srikar Dronamraju wrote: > This patch implements ftrace plugin for uprobes. > > Description: > Ftrace plugin provides an interface to dump data at a given address, top of > the stack and function arguments when a user program calls a specific > function.
So, as told before, ftrace plugins tend to be relegated to obsolescence and I first suggested to plug this into kprobe events so that we have a unified interface to control/create u|k|kret probe events.
But after digging more into first appearances, uprobe creation can follow the kprobes creation flow.
kprobe can be created whenever we want. This is about probing kernel text and it is already there so that we can set the probe, default deactivated, in advance.
This is much more tricky in the case of uprobes as I see two ways to work with it:
- probing on an already running process - probing on a process we are about to run
Now say we create to create a uprobe trace event for an already running process. No problem in the workflow, we just need to set the address and the pid. Fine.
Now what if I want to launch ls and want to profile a function inside. What can I do with a trace event. I can't create the probe event based on a pid as I don't know it in advance. I could give it the ls cmdline and it manages to activate on the next ls launched. This is racy as another ls can be launched concurrently.
So I can only say there that an ftrace plugin or an ftrace trace event would be only a half-useful interface to exploit utrace possibilities because it only lets us trace already running apps. Moreover I bet the most chosen workflow to profile/trace uprobes is by launching an app and profile it from the beginning, not by profiling an already running one, which makes an ftrace interface even less than half useful there.
ftrace is cool to trace the kernel, but this kind of tricky userspace tracing workflow is not adapted to it.
What do you think?
| |