Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 09:45 AM, Peter Zijlstra wrote: This is debugging. We're playing with registers, we're playing with the cpu, we're playing with memory contents. Why not the address space as well? Because you want thins go to be as transparent as possible in order to avoid heisenbugs.

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Peter Zijlstra
On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote: You've made it clear that you don't like it, but not why. The kernel already manages the user's address space (except for MAP_FIXED which is unreliable unless you've already reserved the address space). I don't see why adding a vma

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Peter Zijlstra
On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote: If we reserve some address space, you don't add any heisenbugs (at least, not any additional ones over emulation). Even if we don't, address space layout randomization means we're not keeping the address space layout constant between

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 01:44 PM, Peter Zijlstra wrote: On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote: You've made it clear that you don't like it, but not why. The kernel already manages the user's address space (except for MAP_FIXED which is unreliable unless you've already reserved the

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Peter Zijlstra
On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote: Maybe you place no value on uprobes. But people who debug userspace likely will see a reason. I do see value in uprobes, I just don't like it mucking about with the address space. Nor does it appear required.

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 02:06 PM, Peter Zijlstra wrote: On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote: Maybe you place no value on uprobes. But people who debug userspace likely will see a reason. I do see value in uprobes, I just don't like it mucking about with the address space. Nor

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Pekka Enberg
Hi Avi, On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote: Maybe you place no value on uprobes.  But people who debug userspace likely will see a reason. On 01/18/2010 02:06 PM, Peter Zijlstra wrote: I do see value in uprobes, I just don't like it mucking about with the address space. Nor

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 02:13 PM, Pekka Enberg wrote: So how big chunks of the address space are we talking here for uprobes? That's for the authors to answer, but at a guess, 32 bytes per probe (largest x86 instruction is 15 bytes), so 32 MB will give you a million probes. That's a piece of cake

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Peter Zijlstra
On Mon, 2010-01-18 at 14:17 +0200, Avi Kivity wrote: On 01/18/2010 02:13 PM, Pekka Enberg wrote: So how big chunks of the address space are we talking here for uprobes? That's for the authors to answer, but at a guess, 32 bytes per probe (largest x86 instruction is 15 bytes), so 32

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Srikar Dronamraju
* Avi Kivity a...@redhat.com [2010-01-18 14:17:10]: On 01/18/2010 02:13 PM, Pekka Enberg wrote: So how big chunks of the address space are we talking here for uprobes? That's for the authors to answer, but at a guess, 32 bytes per probe (largest x86 instruction is 15 bytes), so 32 MB will

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Pekka Enberg
On Mon, Jan 18, 2010 at 2:44 PM, Srikar Dronamraju sri...@linux.vnet.ibm.com wrote: * Avi Kivity a...@redhat.com [2010-01-18 14:17:10]: On 01/18/2010 02:13 PM, Pekka Enberg wrote: So how big chunks of the address space are we talking here for uprobes? That's for the authors to answer, but at

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than enough? I don't think a user will ever come close to a million, but we can expect some inflation from inlined

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Pekka Enberg
On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than enough? Avi Kivity kirjoitti: I don't think a user will ever come close to a million, but we can expect some inflation

Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

2010-01-18 Thread Frederic Weisbecker
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

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 02:57 PM, Pekka Enberg wrote: On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than enough? Avi Kivity kirjoitti: I don't think a user will ever come close to a

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Peter Zijlstra
On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote: On 01/18/2010 02:14 PM, Peter Zijlstra wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple of jumps. With CPL2 or RPL on user segments the protection

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 03:15 PM, Peter Zijlstra wrote: On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote: On 01/18/2010 02:14 PM, Peter Zijlstra wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple of

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Mark Wielaard
On Mon, 2010-01-18 at 14:53 +0200, Avi Kivity wrote: On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than enough? I don't think a user will ever come close to a

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread K.Prasad
On Mon, Jan 18, 2010 at 02:15:51PM +0100, Peter Zijlstra wrote: On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote: On 01/18/2010 02:14 PM, Peter Zijlstra wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Ananth N Mavinakayanahalli
On Mon, Jan 18, 2010 at 02:13:25PM +0200, Pekka Enberg wrote: Hi Avi, On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote: Maybe you place no value on uprobes.  But people who debug userspace likely will see a reason. On 01/18/2010 02:06 PM, Peter Zijlstra wrote: I do see value in

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Masami Hiramatsu
Jim Keniston wrote: Not really. For #3 (boosting), you need to know everything for #2, plus be able to compute the length of each instruction -- which we can now do for x86. To emulate an instruction (#4), you need to replicate what it does, side-effects and all. The x86 instruction

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Avi Kivity
On 01/18/2010 05:43 PM, Ananth N Mavinakayanahalli wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple of jumps. So how big chunks of the address space are we talking here for uprobes? As Srikar

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Ananth N Mavinakayanahalli
On Mon, Jan 18, 2010 at 06:52:32PM +0200, Avi Kivity wrote: On 01/18/2010 05:43 PM, Ananth N Mavinakayanahalli wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple of jumps. So how big chunks of the address

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Jim Keniston
On Mon, 2010-01-18 at 10:58 -0500, Masami Hiramatsu wrote: Jim Keniston wrote: Not really. For #3 (boosting), you need to know everything for #2, plus be able to compute the length of each instruction -- which we can now do for x86. To emulate an instruction (#4), you need to

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Jim Keniston
On Mon, 2010-01-18 at 14:34 +0100, Mark Wielaard wrote: On Mon, 2010-01-18 at 14:53 +0200, Avi Kivity wrote: On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-18 Thread Masami Hiramatsu
Jim Keniston wrote: On Mon, 2010-01-18 at 10:58 -0500, Masami Hiramatsu wrote: Jim Keniston wrote: Not really. For #3 (boosting), you need to know everything for #2, plus be able to compute the length of each instruction -- which we can now do for x86. To emulate an instruction (#4),

Re: PTRACE_SYSCALL_ENTRY/EXIT

2010-01-18 Thread Roland McGrath
We don't have any particular plans to extend the ptrace interface. I strongly doubt we would even try to do anything like that until the utrace-based ptrace interface is merged into Linux and the old ptrace implementation gone. In general, we are not looking for extensions to the ptrace