Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes

Srikar Dronamraju
2011-03-15T02:03:35Z

> >
> > 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.
>

Right, So I am looking at having perf probe for uprobes and also at
having a syscall so that perf probe and other ptrace users can use this
infrastructure. Ingo has already asked for a syscall for the same in
one of his replies to my previous patchset. From whatever
discussions I had with ptrace users, they have shown interest in
using this breakpoint infrastructure.

I am still not sure if this feature should be exposed thro a new
operation to ptrace syscall (something like SET_BP) or a completely new
syscall or both. I would be happy if people here could give inputs on
which route to go forward.

We had perf probe for uprobes implemented in few of the previous
patchset. When the underlying implementation changed from a
pid:vaddr to a file:offset, the way we invoke perf probe changed.

Previously we would do
"perf probe -p 3692 zfree@zsh"

Now we would be doing
"perf probe -u zfree@zsh"

The perf probe for uprobes is still WIP. Will post the patches when it
is in usable fashion. This should be pretty soon.

If you have suggestions on how this infrastructure could be used
above perf probe and syscall, then please do let me know.

--
Thanks and Regards
Srikar