From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28865 invoked by alias); 13 May 2009 15:04:37 -0000 Received: (qmail 28383 invoked by uid 22791); 13 May 2009 15:04:34 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 May 2009 15:04:29 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4DF4SbG021858; Wed, 13 May 2009 11:04:28 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4DF4R8l014999; Wed, 13 May 2009 11:04:27 -0400 Received: from localhost.localdomain (vpn-14-23.rdu.redhat.com [10.11.14.23]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4DF4PZE001952; Wed, 13 May 2009 11:04:26 -0400 Message-ID: <4A0AE179.9050801@redhat.com> Date: Wed, 13 May 2009 15:04:00 -0000 From: David Smith User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Roland McGrath CC: Maynard Johnson , systemtap@sourceware.org, "Frank Ch. Eigler" Subject: Re: Backward compatibility for insn probe point References: <49D3E3DF.1000108@us.ibm.com> <49F61D09.8090503@redhat.com> <49F8C1C0.8070208@us.ibm.com> <49F9E71D.2070500@redhat.com> <20090430203302.5FFA0FC3BF@magilla.sf.frob.com> <4A099E6B.8090501@redhat.com> <20090512181950.19BCCFC35D@magilla.sf.frob.com> In-Reply-To: <20090512181950.19BCCFC35D@magilla.sf.frob.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00572.txt.bz2 Roland McGrath wrote: > Ok, that is on the verge of ringing a bell. > > The single-step trap hit resets the single-step bit in the registers > (arch/powerpc/kernel/traps.c:single_step_exception). That needs to be > turned on again before resuming. The only place that this happens is > utrace_quiescent->tracehook_enable_single_step. You should get there via > check_quiescent after each event report when UTRACE_ACTION_STATE_* is set. > > It makes sense that ptrace does not see the same problem. It always stops > after each step trap, so it surely goes into utrace_quiescent to stop; > there it will properly re-enable stepping when it gets resumed. In the > itrace scenario, you don't stop, so it's only the (apparently broken) > bookkeeping that should ensure you get there. > > In a reporting loop, update_action should be keeping UTRACE_ACTION_SINGLESTEP > in its return value, so that check_quiescent see it and calls utrace_quiescent. > You can see if some of that is going wrong. > > (This is all entirely different in modern utrace.) I poked around the kernel source some more, but couldn't see what was going wrong. So, I decided to attack the problem from a different angle, based on what you said above. I've changed the itrace code to stop the task after each step trap (so that it acts more like ptrace). I've tested this on several kernels (2.6.18-141.el5/ppc, 2.6.18-128.1.10.el5/x86_64/i686, and 2.6.25-14.fc9.ppc64) and it seems to work correctly. Does this seem like a reasonable work-around? Could there be problems with this approach? Thanks. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)