From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6600 invoked by alias); 3 Feb 2006 18:39:07 -0000 Received: (qmail 6591 invoked by uid 22791); 3 Feb 2006 18:39:06 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Feb 2006 18:39:04 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k13Id0NN004239 for ; Fri, 3 Feb 2006 13:39:00 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k13Id08n225528 for ; Fri, 3 Feb 2006 13:39:00 -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 k13IcxGx017888 for ; Fri, 3 Feb 2006 13:38:59 -0500 Received: from [127.0.0.1] (sig-9-65-4-11.mts.ibm.com [9.65.4.11]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k13IcvK4017697; Fri, 3 Feb 2006 13:38:58 -0500 Message-ID: <43E3A33F.1050005@us.ibm.com> Date: Fri, 03 Feb 2006 18:39: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: "Stone, Joshua I" CC: "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: user kprobes vs debuggers References: In-Reply-To: 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/msg00380.txt.bz2 Stone, Joshua I wrote: >Vara Prasad wrote: > > > [...] > >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. > > Let us say if there is no user space probes involved debugger remembers the original instruction before replacing it is with breakpoint instruction. It single steps the original instruction that is stored in the userspace. Let us say if there is no debugger and there is only userspace probes userspace pobes does the same single stepping but in the kernel space. Another important distinction to remember here is each of them have their own handlers to run when the break point is hit. Based on the above background there is a global registry of the breakpoints in the kernel that is only used to notify who all would like to handle this breakpoint but it is up to each of the owners to run their own handlers and as well as handle single stepping. One complication in this problems is the applications that have compiled breakpoint instructions, but i am not sure how common that occurrence is and like i mentioned in my earlier reply we may be able to handle them as well. Does this answer your question? >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. > > I think it would have been o.k to disallow but due to common uses like strace people might object to userspace probes feature. > >Josh > > >