On Wed, Jan 20, 2010 at 12:10:26PM +0530, Ananth N Mavinakayanahalli wrote:
It will cause conflicts with various other trees and increases the overhead
all around. It also causes us to trust linux-next bugreports less - as it's
not the 'next Linux' anymore. Also, there's virtually no
On Wed, Jan 20, 2010 at 12:06:20PM +0530, Srikar Dronamraju wrote:
* Frederic Weisbecker fweis...@gmail.com [2010-01-19 19:06:12]:
On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote:
What does the code in the jumped-to vma do? Is the instrumentation code
that corresponds
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
On Thu, Jan 14, 2010 at 01:29:09PM +0100, Peter Zijlstra wrote:
On Thu, 2010-01-14 at 13:23 +0100, Frederic Weisbecker wrote:
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?
Right, so either we have
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
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
On Mon, Jan 11, 2010 at 05:56:08PM +0530, Srikar Dronamraju wrote:
This patch implements ftrace plugin for uprobes.
Description:
Ftrace plugin provides an interface to dump data at a given address, top of
the stack and function arguments when a user program calls a specific
function.
So,
On Fri, Dec 18, 2009 at 12:05:03PM -0800, Roland McGrath wrote:
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the
On Fri, Dec 18, 2009 at 03:10:42AM +0100, Oleg Nesterov wrote:
On 12/17, Roland McGrath wrote:
Comparing to the old (2.6.32) logic, I think it might be this (untested).
I also note this is the sole use of get_si_code, seems like it should
just be rolled in here.
Well, it is too late
On Mon, Mar 16, 2009 at 06:18:00PM -0400, Frank Ch. Eigler wrote:
Hi -
On Mon, Mar 16, 2009 at 05:45:26PM -0400, Mathieu Desnoyers wrote:
[...]
As far as I know, utrace supports multiple trace-engines on a process.
Since ptrace is just an engine of utrace, you can add another
10 matches
Mail list logo