Frederic Weisbecker wrote: > On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote: >>> Do you have plans for a variant >>> that's completely in userspace? >> >> I don't know of any such plans, but I'd be interested to read more of >> your thoughts here. As I understand it, you've suggested replacing the >> probed instruction with a jump into an instrumentation vma (the XOL >> area, or something similar). Masami has demonstrated -- through his >> djprobes enhancement to kprobes -- that this can be done for many x86 >> instructions. >> >> What does the code in the jumped-to vma do? Is the instrumentation code >> that corresponds to the uprobe handlers encoded in an ad hoc .so? > > > Once the instrumentation is requested by a process that is not the > instrumented one, this looks impossible to set a uprobe without a > minimal voluntary collaboration from the instrumented process > (events sent through IPC or whatever). So that looks too limited, > this is not anymore a true dynamic uprobe.
Agreed. Since uprobe's handler must be running in kernel, we need to jump into kernel space anyway. "Booster" (just skips a single-stepping(trap) exception) may be useful for improving uprobe performance. And also as Andi said, using jump instead of int3 in userspace has 2GB address space limitation. It's not a problem for kernel inside, but a big problem in userspace. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhira...@redhat.com