From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11910 invoked by alias); 27 Feb 2006 18:18:00 -0000 Received: (qmail 11856 invoked by uid 22791); 27 Feb 2006 18:17:58 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 27 Feb 2006 18:17:55 +0000 Received: by xproxy.gmail.com with SMTP id t10so607658wxc for ; Mon, 27 Feb 2006 10:17:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YJ1a+tN0ydkljXWHKg5nHM4amkx0W1Y5inlZ3IH4dRVbCoHomDEfzCIHNdBhjOa8VsoQZxVtGa0GpH+s0CJkrVidIUKUK4p/ud1pyLt6fDLb/N4ZXxx0BMspixqOlQllY/n68/yQ8Ir0P2WZw/f7Kssk/qRr01UNKTRmeNW6/Qc= Received: by 10.70.23.18 with SMTP id 18mr1872757wxw; Mon, 27 Feb 2006 10:17:52 -0800 (PST) Received: by 10.70.33.17 with HTTP; Mon, 27 Feb 2006 10:17:52 -0800 (PST) Message-ID: Date: Mon, 27 Feb 2006 18:18:00 -0000 From: "James Dickens" To: "Richard J Moore" Subject: Re: Single-stepping with interrupts enabled. Cc: "systemtap@sources.redhat.com" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: 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/msg00646.txt.bz2 On 2/27/06, Richard J Moore wrote: > > > > > Effectively we do that (and I note that the Dtrace guys read my paper on > how to do this ;-)), however to do better than that one might consider > enabling interrupts or allowing signals during the single-step. Seems like enabling interups and allowing signals during the single step is just asking for problems, dtrace's implementation of your ideas seems rock stable, I have tested it out by testing 32 dtrace apps ( plockstat) running at the same time on a SMP system and had no problems. And others have done even more testing. It would be best to get basic functionality working, before you move to the next step, enabling interupts and signals. James > - - > Richard J Moore > IBM Advanced Linux Response Team - Linux Technology Centre > MOBEX: 264807; Mobile (+44) (0)7739-875237 > Office: (+44) (0)1962-817072 > > > > "James Dickens" > l.com> To > Richard J Moore/UK/IBM@IBMGB > 27/02/2006 cc > 17:13 "systemtap@sources.redhat.com" > > bcc > > Subject > Re: Single-stepping with interrupts > enabled. > > > > > > > On 2/27/06, Richard J Moore wrote: > > > > > > > > > > A couple of weeks ago the topic of single-stepping came up on the > > conference call. I said, I'd document the technical consideration over > > allowing that to happen - and why it has not been implemented in the > > general case. > > > > > > The problem is down to the need to save state over the single-step, so > that > > pre- and post-processing either side of the single-step can be correctly > > associated with each other. The difficulties that arise when interrupts > are > > enabled are two-fold, but only manifest themselves when a user-space > > instruction is single-stepped. > > A lot of problems can be solved if you use some of the methodology > that dtrace uses. Where they do most single stepping in a scratch > space and defers signals till after were done with our probing. > > > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/intel/dtrace/fasttr= ap_isa.c > > 44 * Most instructions' execution is not dependent on their > address; for these > 45 * instrutions it is sufficient to copy them into the user > process's address > 46 * space and execute them. To effectively single-step an > instruction in > 47 * user-land, we copy out the following sequence of > instructions to scratch > 48 * space in the user thread's ulwp_t structure. > 49 * > 50 * We then set the program counter (%eip or %rip) to point to > this scratch > 51 * space. Once execution resumes, the original instruction is > executed and > 52 * then control flow is redirected to what was originally the > subsequent > 53 * instruction. If the kernel attemps to deliver a signal while > single- > 54 * stepping, the signal is deferred and the program counter is > moved into the > 55 * second sequence of instructions. The second sequence ends > in a trap into > 56 * the kernel where the deferred signal is then properly > handled and delivered. > 57 * > 58 * For instructions whose execute is position dependent, we > perform simple > 59 * emulation. These instructions are limited to control transfer > 60 * instructions in 32-bit mode, but in 64-bit mode there's the > added wrinkle > 61 * of %rip-relative addressing that means that almost any > instruction can be > 62 * position dependent. For all the details on how we emulate > generic > 63 * instructions included %rip-relative instructions, see the code > in > 64 * fasttrap_pid_probe() below where we handle instructions of type > 65 * FASTTRAP_T_COMMON (under the header: Generic Instruction > Tracing). > 66 */ > > James Dickens > uadmin.blogspot.com > > > [snipped] > > > > - - > > Richard J Moore > > IBM Advanced Linux Response Team - Linux Technology Centre > > MOBEX: 264807; Mobile (+44) (0)7739-875237 > > Office: (+44) (0)1962-817072 > > > > > > >