Re: malloc() tracing in perf?

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

On Thu, Aug 06, 2009 at 02:59:34PM +0200, Peter Zijlstra wrote:

> [...]  Yeah in plain sight where nobody looks, really I thought the
> idea was to get utrace upstream, this means posting to
> linux-kernel. Going on LKML posts [...]

I don't wish to get into arguing about how much lkml posting is
appropriate, or to editorialize about what happened when some of this
code did actually get posted.  I'm simply discussing the technology.
It's never been hard to find.


> [...]
> Does this also iterate the already existing tasks to find if it was
> already mmap()ed?

Yes.

> > This overview skims over issues related to return probes, tracing
> > buffer manipulations, and much other stuff.
> 
> Right, so you basically read the (dwarf2) debug info for a particular
> lib/symbol and generate a kernel module that knows about that and then
> insert that into the kernel to act as a uprobe handler?

Yes.

> Uprobe will then do the code rewrite on mmap() time to insert a trap
> much like kprobe does? What if its a JITed code section and the JIT
> rewrites it? Will uprobes detect that?

You mean if the uprobe is made to refer to code that was created by a
JIT?  That does not happen in the preceding scenario, since the
uprobes addresses were based on prior generated debugging data.

Putting uprobes into JIT code such as LLVM or JVM code is something
for the future.


> > All the code for this is hidden in plain sight in every systemtap
> > release, so please feel free to refer to that and/or ask more detailed
> > questions.
> 
> I thought the goal was to get stuff upstream, but if you want to
> continue living in la-la land and not bother with upstream Linux then so
> be it I guess :-(

It's not that simple, and you know it.


- FChE