From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 832 invoked by alias); 8 Feb 2011 21:07:57 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 821 invoked by uid 22791); 8 Feb 2011 21:07:56 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Tue, 08 Feb 2011 21:07:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: Jan Kratochvil , Project Archer Subject: Re: ptrace improvement ideas Message-ID: <20110208205953.GA15932@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110207211129.GA23277@host1.dyn.jankratochvil.net> <20110208015844.B994A1814A4@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110208015844.B994A1814A4@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2011-q1/txt/msg00037.txt.bz2 On 02/07, Roland McGrath wrote: > > > There is already AFAIK some abstraction of DR regiters inside kernel so maybe > > userland could get access to this abstraction to resolve these two issues. > > Indeed, there is now a layer called hw_breakpoint, with in-kernel APIs that > are largely machine-independent. The legacy arch-specific ptrace interface > for x86 is implemented on top of that (not purely so, but rather supported > by that infrastructure as special cases). I think Oleg knows the details > of that stuff better than I do at this point. Yes, and hw_breakpoint is implemented on top of perf counters. > I think the desireable approach is to figure out a new interface (ptrace > extension, presumably) to use those new facilities directly from user > space. It should be possible for such a new interface to be largely > machine-independent too. Probably yes... but it is not clear to me how exactly the new interface should look. And it should coexist with the current ->ptrace_bps[] code. And while register_user_hw_breakpoint() itself is arch independent, there are still some details. Say, if the tracee traps, the tracer should know somehow which bp was the reason. But I agree it would be nice to have the simple "abstract" interface. Jan, if you have any idea about how it should look - please tell us. I _think_ that the actual implementation shoudn't be very very difficult, although I can't say I understand this code in details. > > It must explicitly require debug registers (hw watchpoints) inheritance. > > Which happened before but it no longer happens in recent upstream kernels > > (NOTABUG RH#660003). > > That is a good point and one I had not been thinking of, Oh, yes, I missed this too. > It's my feeling that the > right way to approach this is to focus on a new set of interfaces built on > the kernel's hw_breakpoint facility (that infrastructure may well need > extending to deal well with userland better). Those can be defined with > the inheritance and process-wide sharing issues in mind, Hmm. This is also not clear to me... Oleg.