Re: [RFC] [PATCH] selective signal ptracing

2007-06-18 Thread Benjamin Herrenschmidt
On Mon, 2007-06-18 at 08:15 -0500, Josh Boyer wrote: > On 6/16/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > > > What are the issues with arch like ARM ? > > > > The interesting class ARM belongs to is machines that don't (or don't > > always) have hardware support for single-step. Maintaining t

Re: [RFC] [PATCH] selective signal ptracing

2007-06-18 Thread John Blackwood
> Subject: Re: [RFC] [PATCH] selective signal ptracing > From: Oleg Nesterov <[EMAIL PROTECTED]> > Date: Sat, 16 Jun 2007 13:24:15 +0400 > To: John Blackwood <[EMAIL PROTECTED]> > CC: Alan Cox <[EMAIL PROTECTED]>, Roland McGrath <[EMAIL PROTECTED]>,

Re: [RFC] [PATCH] selective signal ptracing

2007-06-18 Thread Josh Boyer
On 6/16/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines i

Re: [RFC] [PATCH] selective signal ptracing

2007-06-16 Thread Roland McGrath
> What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is f

Re: [RFC] [PATCH] selective signal ptracing

2007-06-16 Thread Benjamin Herrenschmidt
On Sat, 2007-06-16 at 00:26 +0100, Alan Cox wrote: > On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) > Roland McGrath <[EMAIL PROTECTED]> wrote: > > > I am not in favor of any enhancements to the ptrace interface. > > It is a terrible interface and just needs to die. > > That might make sense if utrace

Re: [RFC] [PATCH] selective signal ptracing

2007-06-16 Thread Oleg Nesterov
John Blackwood wrote: > > By default all signals are ptraced as before. However, a debugger > may now modify the set of per-task ptraced signals, where only the > signals in this ptrace signal mask will be ptraced. I must admit, I agree with Roland... > +void ptrace_update_traced_signals(struct t

Re: [RFC] [PATCH] selective signal ptracing

2007-06-15 Thread Roland McGrath
> That might make sense if utrace ever looked like it would solve the > questions about platforms like ARM It certainly will. The only difficult limitations have been in communication and understanding. Please don't perpetuate a generic red herring without adding any content to the subject. Th

Re: [RFC] [PATCH] selective signal ptracing

2007-06-15 Thread Alan Cox
On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]> wrote: > I am not in favor of any enhancements to the ptrace interface. > It is a terrible interface and just needs to die. That might make sense if utrace ever looked like it would solve the questions about platforms lik

Re: [RFC] [PATCH] selective signal ptracing

2007-06-15 Thread Roland McGrath
I am not in favor of any enhancements to the ptrace interface. It is a terrible interface and just needs to die. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/ma

[RFC] [PATCH] selective signal ptracing

2007-06-15 Thread John Blackwood
Selective Ptraced Signal Support - A proposed enhancement This is a proposal for a ptrace enhancement that adds two new ptrace(2) commands that let a debugger view and modify the set of signals that are being ptraced. By default all signals are ptraced as before. However, a debugger may now modi