On 01/16/2010 02:58 AM, Jim Keniston wrote:
I hear (er, read) you. Emulation may turn out to be the answer for some
architectures. But here are some things to keep in mind about the
various approaches:
1. Single-stepping inline is easiest: you need to know very little about
the instruction
On Sun, 2010-01-17 at 16:56 +0200, Avi Kivity wrote:
On 01/17/2010 04:52 PM, Peter Zijlstra wrote:
Also, if its fixed size you're imposing artificial limits on the number
of possible probes.
Obviously we'll need a limit, a uprobe will also take kernel memory, we
can't allow people
On Sun, 2010-01-17 at 16:59 +0200, Avi Kivity wrote:
On 01/17/2010 04:52 PM, Peter Zijlstra wrote:
On Sun, 2010-01-17 at 16:39 +0200, Avi Kivity wrote:
On 01/15/2010 11:50 AM, Peter Zijlstra wrote:
As previously stated, I think poking at a process's address space is an
utter
On 01/17/2010 05:03 PM, Peter Zijlstra wrote:
btw, an alternative is to require the caller to provide the address
space for this. If the caller is in another process, we need to allow
it to play with the target's address space (i.e. mmap_process()). I
don't think uprobes justifies this by
On Sat, 2010-01-16 at 18:48 -0500, Jim Keniston wrote:
As you may have noted before, I think FP would be a special problem
for your approach. I'm not sure how folks would react to the idea of
executing FP instructions in kernel space. But emulating them is also
tough. There's an IEEE
On Sat, 2010-01-16 at 19:12 -0500, Bryan Donlan wrote:
On Fri, Jan 15, 2010 at 7:58 PM, Jim Keniston jkeni...@us.ibm.com wrote:
4. Emulation removes the need for the XOL area, but requires pretty much
total knowledge of the instruction set. It's also a performance win for
architectures
On Sun, 2010-01-17 at 21:33 +0200, Avi Kivity wrote:
On 01/17/2010 05:03 PM, Peter Zijlstra wrote:
btw, an alternative is to require the caller to provide the address
space for this. If the caller is in another process, we need to allow
it to play with the target's address space (i.e.
