Subject: Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes
From: Jim Keniston <jkenisto@us.ibm.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>, Ingo Molnar <mingo@elte.hu>,
       Arnaldo Carvalho de Melo <acme@infradead.org>,
       Peter Zijlstra <peterz@infradead.org>,
       Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
       utrace-devel <utrace-devel@redhat.com>, Mark Wielaard <mjw@redhat.com>,
       Frederic Weisbecker <fweisbec@gmail.com>,
       Maneesh Soni <maneesh@in.ibm.com>, LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <4B4B373B.5010802@redhat.com>
References: <20100111122521.22050.3654.sendpatchset@srikar.in.ibm.com>
	 <4B4B373B.5010802@redhat.com>
Content-Type: text/plain
Date: Mon, 11 Jan 2010 14:59:32 -0800
Message-Id: <1263250772.5094.41.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2509
Lines: 64


On Mon, 2010-01-11 at 09:35 -0500, Masami Hiramatsu wrote:
> Srikar Dronamraju wrote:
> > Hi, 
> > 
> > This patchset implements Uprobes which enables you to dynamically
> > break into any routine in a user space application and collect
> > information non-disruptively.  Uprobes is based on utrace and uses
> > x86 instruction decoder.
...
> 
> > - Return probes.
> 
> Hmm, I think we need some symbol information for supporting
> return probes in user space. Could you tell me how to work it?
> is that requires some user-space helper?

Return probes are on the TODO list, but we actually already have a
pretty solid implementation of that.  It's held out for now because
Srikar's patch set is already big, and we want get a review of the basic
ubp/xol/uprobes feature.

For the most part, we don't need special symbol information for return
probes.  We just do as we did in kretprobes: hijack the return address
and replace it with the address of a trampoline.  In user-space return
probes, the trampoline is one of the instruction slots in the XOL vma,
and contains a breakpoint to trap us into the kernel.  (Of course, as in
kretprobes, we need to know the address of the function so we can hijack
the return address upon entry to the function.)

One place where symbol info would come in handy is when a function
returns in a weird way.  We handle longjmps by noticing that the task's
stack is smaller than expected, and presumably missing stack frames that
were bypassed by the longjmp.  But this heuristic gets dicey when you
consider that in a 32-bit x86 app, a struct-returning function pops not
only the return address upon return, but also the address of the
returned struct value.  So it'd be nice to know if a function returns a
struct.

Does this answer your question, or did I miss something?

> 
> > - Support for Other Architectures.
> > - Jump optimization.
> 
> I assume that you meant this is "uprobe-booster" to skip
> just single stepping after probing, isn't it?

Yes, I think that's what Srikar meant: avoid single-stepping by adding a
jump instruction after the instruction-copy in the XOL slot -- as you
did in your kprobes-booster work.  Your instruction-analysis work makes
this much more feasible.

> 
> 
> Thank you,

Jim Keniston

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/