From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23896 invoked by alias); 3 Feb 2006 06:37:27 -0000 Received: (qmail 23888 invoked by uid 22791); 3 Feb 2006 06:37:26 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Feb 2006 06:37:25 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k136bMsd003515 for ; Fri, 3 Feb 2006 01:37:22 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k136bMxP198170 for ; Fri, 3 Feb 2006 01:37:22 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k136bMPG009937 for ; Fri, 3 Feb 2006 01:37:22 -0500 Received: from [127.0.0.1] (sig-9-49-135-84.mts.ibm.com [9.49.135.84]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k136bJHa009859; Fri, 3 Feb 2006 01:37:21 -0500 Message-ID: <43E2FA1E.5070901@us.ibm.com> Date: Fri, 03 Feb 2006 06:37:00 -0000 From: Vara Prasad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: systemtap@sources.redhat.com Subject: Re: user kprobes vs debuggers References: <20060202192231.GA29179@redhat.com> In-Reply-To: <20060202192231.GA29179@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00375.txt.bz2 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. In the above discussion i didn't differentiate between /proc/pid/mem and ptrace() as they both go through the same interface in the kernel they are equivalent for this discussion. I think this mechanism should handle applications that have breakpoints builtin as well because i am thinking they are going to use ptrace interface as well to register the breakpoint, is that correct. Did i not consider something in the above design? Frank Ch. Eigler wrote: >Hi - > >During the teleconference earlier today, we discussed the issue of >coexistence of user-mode kprobes (along the favoured #4 path) with >debuggers, manipulating the same tasks. > >The core issue is that both systems insert breakpoints into pages >of the target text. Ideally, we would like both systems to operate >independently, unaware of each other. But: > >Without synchronization over "ownership" of the text pages, two >systems may perform the insertion or removal interleaved in an >inconvenient way. It may be possible to lose breakpoints, or even to >create spontaneous ones. To perform sufficient synchronization, we >may need to (a) detect possible conflicts after the fact, (b) bluntly >block one system when the other is active, (c) hook user-kprobes into >ptrace and /proc/mem code paths to intercept debuggers' operations >and/or (d) provide a virtualization facility where the user-space >tools only see a kprobe-less image of the real text page. > >A related problem is handling of breakpoints once triggered. Clearly >user-kprobes get to run first. The system needs to know whether user >space has also set a breakpoint at the same spot, so a subsequent >ptrace signal can be propagated to the debugger. Some peculiar >applications may put breakpoints into themselves even without a >debugger present, expecting to catch SIGTRAP. Ideally, user kprobes >should work with these too. > >- FChE > > >