Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: User Space Breakpoint Assistance Layer (UBP) User space breakpointing Infrastructure provides kernel subsystems with architecture independent interface to establish breakpoints in user applications. This patch provides core implementation of ubp and also wrappers for architecture dependent methods. So if this is the basic infrastructure to set userspace breakpoints, then why not call this uprobe? UBP currently supports both single stepping inline and execution out of line strategies. Two different probepoints in the same process can have two different strategies. maybe explain wth these are?
Re: [RFC] [PATCH 4/7] Uprobes Implementation
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: Uprobes Infrastructure enables user to dynamically establish probepoints in user applications and collect information by executing a handler functions when the probepoints are hit. Please refer Documentation/uprobes.txt for more details. This patch provides the core implementation of uprobes. This patch builds on utrace infrastructure. You need to follow this up with the uprobes patch for your architecture. So all this is basically some glue between what you call ubp (the real userspace breakpoint stuff) and utrace? Or does it do more?
Re: [RFC] [PATCH 4/7] Uprobes Implementation
On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote: Well, I wonder if perf can ride on utrace's callbacks for the hook_task() for the clone/fork cases? Well it could, but using all of utrace to simply get simple callbacks from copy_process() is just daft so we're not going to do that.
Re: [RFC] [PATCH 3/7] Execution out of line (XOL)
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: Execution out of line (XOL) Slot allocation mechanism for Execution Out of Line strategy in User space breakpointing Inftrastructure. (XOL) This patch provides slot allocation mechanism for execution out of line strategy for use with user space breakpoint infrastructure. This patch requires utrace support in kernel. This patch provides five functions xol_get_insn_slot(), xol_free_insn_slot(), xol_put_area(), xol_get_area() and xol_validate_vaddr(). Current slot allocation mechanism: 1. Allocate one dedicated slot per user breakpoint. 2. If the allocated vma is completely used, expand current vma. 3. If we cant expand the vma, allocate a new vma. Say what? I see the text, but non of it makes any sense at all.
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Just to clarify, this means you can do things like: p:uprobe_event dso:symbol[+offs] Irrespective of whether there are any current user of that file.
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, Jan 14, 2010 at 12:23:11PM +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Then on creation it uses rmap to find all current maps of that file and install the probe if there is a consumer for that map. Then for each new mmap() of that file, we also need to check if there's a consumer ready and install the probe. That looks racy. Say you first create a probe on /bin/ls: perf probe p addr_in_ls /bin/ls then something else launches /bin/ls behind you, probe is set on it then you launch: perf record -e probe: /bin/ls Then it goes recording the previous instance.
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, 2010-01-14 at 12:35 +0100, Frederic Weisbecker wrote: On Thu, Jan 14, 2010 at 12:23:11PM +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Then on creation it uses rmap to find all current maps of that file and install the probe if there is a consumer for that map. Then for each new mmap() of that file, we also need to check if there's a consumer ready and install the probe. That looks racy. Say you first create a probe on /bin/ls: perf probe p addr_in_ls /bin/ls then something else launches /bin/ls behind you, probe is set on it then you launch: perf record -e probe: /bin/ls Then it goes recording the previous instance. Uhm, why? Only the perf /bin/ls instance has a consumer and will thus have a probe installed. (Or if you want to use ftrace you need to always have all instances probed anyway)
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, 2010-01-14 at 12:29 +0100, Peter Zijlstra wrote: On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Just to clarify, this means you can do things like: p:uprobe_event dso:symbol[+offs] Irrespective of whether there are any current user of that file. Yes, that is a good idea, you can then also refine that with a filter on a target pid. That is what systemtap also does, you define files (whether they are executables or shared libraries, etc) plus symbols/offsets/etc as targets and monitor when they get mapped in (either system wide, per executable or pid based). Cheers, Mark
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, 2010-01-14 at 13:16 +0100, Mark Wielaard wrote: On Thu, 2010-01-14 at 12:29 +0100, Peter Zijlstra wrote: On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Just to clarify, this means you can do things like: p:uprobe_event dso:symbol[+offs] Irrespective of whether there are any current user of that file. Yes, that is a good idea, you can then also refine that with a filter on a target pid. That is what systemtap also does, you define files (whether they are executables or shared libraries, etc) plus symbols/offsets/etc as targets and monitor when they get mapped in (either system wide, per executable or pid based). Well, the pid part is more the concern of the consumer of the trace-event. The event itself is task invariant and only cares about the particular code in question getting executed.
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, Jan 14, 2010 at 12:43:01PM +0100, Peter Zijlstra wrote: On Thu, 2010-01-14 at 12:35 +0100, Frederic Weisbecker wrote: On Thu, Jan 14, 2010 at 12:23:11PM +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Then on creation it uses rmap to find all current maps of that file and install the probe if there is a consumer for that map. Then for each new mmap() of that file, we also need to check if there's a consumer ready and install the probe. That looks racy. Say you first create a probe on /bin/ls: perf probe p addr_in_ls /bin/ls then something else launches /bin/ls behind you, probe is set on it then you launch: perf record -e probe: /bin/ls Then it goes recording the previous instance. Uhm, why? Only the perf /bin/ls instance has a consumer and will thus have a probe installed. (Or if you want to use ftrace you need to always have all instances probed anyway) I see, so what you suggest is to have the probe set up as generic first. Then the process that activates it becomes a consumer, right? Would work, yeah.
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Thu, 2010-01-14 at 12:08 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: User Space Breakpoint Assistance Layer (UBP) User space breakpointing Infrastructure provides kernel subsystems with architecture independent interface to establish breakpoints in user applications. This patch provides core implementation of ubp and also wrappers for architecture dependent methods. So if this is the basic infrastructure to set userspace breakpoints, then why not call this uprobe? Ubp is for setting and removing breakpoints, and for supporting the two schemes (inline, out of line) for executing the probed instruction after you hit the breakpoint. Uprobes provides a higher-level API and deals with synchronization issues, process-vs-thread issues, execution of the client's (potentially buggy) probe handler, multiple probe clients, multiple probes at the same location, thread- and process-lifetime events, etc. UBP currently supports both single stepping inline and execution out of line strategies. Two different probepoints in the same process can have two different strategies. maybe explain wth these are? Here's a partial explanation from patch #6,section 1.1: +When a CPU hits the breakpoint instruction, a trap occurs, the CPU's +user-mode registers are saved, and a SIGTRAP signal is generated. +Uprobes intercepts the SIGTRAP and finds the associated uprobe. +It then executes the handler associated with the uprobe, passing the +handler the addresses of the uprobe struct and the saved registers. +... + +Next, Uprobes single-steps its copy of the probed instruction and +resumes execution of the probed process at the instruction following +the probepoint. (It would be simpler to single-step the actual +instruction in place, but then Uprobes would have to temporarily +remove the breakpoint instruction. This would create problems in a +multithreaded application. For example, it would open a time window +when another thread could sail right past the probepoint.) + +Instruction copies to be single-stepped are stored in a per-process +single-step out of line (XOL) area, which is a little VM area +created by Uprobes in each probed process's address space. This (single-stepping out of line = SSOL) is essentially what kprobes does on most architectures. XOL (execution out of line) is actually a broader category that could include other schemes, discussed elsewhere. Jim
Re: [RFC] [PATCH 3/7] Execution out of line (XOL)
On Thu, 2010-01-14 at 12:08 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: Execution out of line (XOL) Slot allocation mechanism for Execution Out of Line strategy in User space breakpointing Inftrastructure. (XOL) This patch provides slot allocation mechanism for execution out of line strategy for use with user space breakpoint infrastructure. This patch requires utrace support in kernel. This patch provides five functions xol_get_insn_slot(), xol_free_insn_slot(), xol_put_area(), xol_get_area() and xol_validate_vaddr(). Current slot allocation mechanism: 1. Allocate one dedicated slot per user breakpoint. 2. If the allocated vma is completely used, expand current vma. 3. If we cant expand the vma, allocate a new vma. Say what? I see the text, but non of it makes any sense at all. Yeah, there's not a lot of context there. I hope it will make more sense if you read section 1.1 of Documentation/uprobes.txt (patch #6). Or look at get_insn_slot() in kprobes, and understand that we're trying to do something similar in uprobes, where the instruction copies have to reside in the user address space of the probed process. Jim
Re: [RFC] [PATCH 4/7] Uprobes Implementation
On Thu, 2010-01-14 at 12:09 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote: Uprobes Infrastructure enables user to dynamically establish probepoints in user applications and collect information by executing a handler functions when the probepoints are hit. Please refer Documentation/uprobes.txt for more details. This patch provides the core implementation of uprobes. This patch builds on utrace infrastructure. You need to follow this up with the uprobes patch for your architecture. So all this is basically some glue between what you call ubp (the real userspace breakpoint stuff) and utrace? Or does it do more? My reply in http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html addresses this. Jim
