From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30452 invoked by alias); 9 Feb 2006 13:59:40 -0000 Received: (qmail 30445 invoked by uid 22791); 9 Feb 2006 13:59:38 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate2.uk.ibm.com (HELO mtagate2.uk.ibm.com) (195.212.29.135) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Feb 2006 13:59:36 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k19DxXm9047862 for ; Thu, 9 Feb 2006 13:59:33 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k19DxXNA220138 for ; Thu, 9 Feb 2006 13:59:33 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k19DxXwD013381 for ; Thu, 9 Feb 2006 13:59:33 GMT Received: from d06ml065.portsmouth.uk.ibm.com (d06ml065.portsmouth.uk.ibm.com [9.149.38.138]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k19DxXv3013375 for ; Thu, 9 Feb 2006 13:59:33 GMT In-Reply-To: <20060206095835.GA6484@in.ibm.com> Subject: Re: user kprobes vs debuggers Sensitivity: To: ananth@in.ibm.com Cc: "Frank Ch. Eigler" , systemtap@sources.redhat.com X-Mailer: Lotus Notes Release 6.5.1IBM February 19, 2004 Message-ID: From: Richard J Moore Date: Thu, 09 Feb 2006 13:59:00 -0000 X-MIMETrack: Serialize by Router on D06ML065/06/M/IBM(Release 6.53HF247 | January 6, 2005) at 09/02/2006 13:59:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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/msg00455.txt.bz2 I honestly think the simplest and only possible general solution is not to allow or support a probe to be placed on any pre-existing breakpoint. The problem we have in general is that we cannot say what the expected outcome of a breakpoint should be. In some cases it will be to terminate the program i.e. exit to system. In others it will be to enter a debugger with the option of resuming at the same or some other point or indeed exiting. In the case of a probepoint, which is more than a mere breakpoint, the processing is complex and automated. Concerns about who handles the debug exception (IA32) apply also to who handles or intercepts any exception generated by a given instruction. To support multiple uses of a breakpoint we would need to establish a protocol that all users would adhere to and a set of APIs to support all users and multiple concurrent users of APIs. Unless someone can point to a real need to multi-user breakpoints I suggest we shelve this with the caveat that probes placed on breakpoints and breakpoints placed on probes are not supported. We can protect ourself from trouble by putting a test in kprobes (1) on probe insertion to make sure that we don't install a probe on a breakpoint and possibly (2) at single-step to make sure that we don't SS a breakpoint. ptrace should probably make a similar test on breakpoint insertion. - - Richard J Moore IBM Advanced Linux Response Team - Linux Technology Centre MOBEX: 264807; Mobile (+44) (0)7739-875237 Office: (+44) (0)1962-817072 systemtap-owner@sourceware.org wrote on 06/02/2006 09:58:35: > On Thu, Feb 02, 2006 at 02:22:31PM -0500, 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. > > Just as a datapoint, atleast on PowerPC, kprobes (and xmon) use a > different "BREAKPOINT" opcode from the one used by GDB so, handling most > cases above should be trivial. In fact, we already handle the > possibility that a different debugger/trace tool may have inserted a > breakpoint at a given location (ref: is_trap() in kernel sources). > > Breakpoints at the same address in userspace is a more tricky issue > though. > > Ananth