From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4057 invoked by alias); 3 Feb 2006 17:43:29 -0000 Received: (qmail 4049 invoked by uid 22791); 3 Feb 2006 17:43:29 -0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from fmr23.intel.com (HELO scsfmr003.sc.intel.com) (143.183.121.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Feb 2006 17:43:28 +0000 Received: from scsfmr101.sc.intel.com (scsfmr101.sc.intel.com [10.3.253.10]) by scsfmr003.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k13HhKux027501; Fri, 3 Feb 2006 17:43:20 GMT Received: from scsmsxvs041.sc.intel.com (scsmsxvs041.sc.intel.com [10.3.90.10]) by scsfmr101.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k13HcI21012080; Fri, 3 Feb 2006 17:38:43 GMT Received: from scsmsx331.amr.corp.intel.com ([10.3.90.4]) by scsmsxvs041.sc.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006020309431317934 ; Fri, 03 Feb 2006 09:43:15 -0800 Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 09:43:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: user kprobes vs debuggers Date: Fri, 03 Feb 2006 17:43:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: user kprobes vs debuggers Thread-Index: AcYojE+Iby7IVxGzRzavUm0QtBTS+gAWkt3w From: "Stone, Joshua I" To: "Vara Prasad" , "Frank Ch. Eigler" Cc: X-OriginalArrivalTime: 03 Feb 2006 17:43:11.0394 (UTC) FILETIME=[4D2D4020:01C628E9] X-Scanned-By: MIMEDefang 2.52 on 10.3.253.10 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00379.txt.bz2 Vara Prasad wrote: > Well come to think of this problem i am thinking this is very similar > to the problem between Kprobes and kernel debuggers. > I am thinking we can have a common interface that ptrace and userspace > probes can use to register break points similar to the notifiers for > kernel probes. The common interface stores the information about all > the break points including the ones from the ptrace interface. There > is a tag on the breakpoint that specifies whether the breakpoint is > inserted by the userspace probes or ptrace. Similar to kernel > multiple probe handlers at a probe point, we could have multiple > probe handlers for user space probes as well. One of the probe > handler among the multiple could be to pass it to the debugger for > the probes registered by ptrace. When the break point is hit > userspace probes gets the control and checks if there is a userspace > probe point at this location, if yes, runs the userspace probes > handler and if there is a ptrace registered probe point at the same > location pass it debugger as well. Unregistering probes of both > types requires updating the global registery of the probe points.=20 Who will single-step the original instruction in this scenario? It seems that the only feasible answer is that the debugger will do it. But, in the case of a probe inserted sooner than the debugger breakpoint, the debugger doesn't know the original instruction. And if the debugger removes its breakpoint, the probe-management would have to start single-stepping. Someone mentioned solving this by presenting the debugger with a virtualized address-space (where the probe doesn't exist). This may be possible, but in the keep-it-simple spirit I think it would be best to just reject the second-comer. At least with a common interface we can detect the conflict, so I think it's fine to just disallow the situation. Josh