From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17778 invoked by alias); 16 Jun 2006 00:59:43 -0000 Received: (qmail 17766 invoked by uid 22791); 16 Jun 2006 00:59:43 -0000 X-Spam-Check-By: sourceware.org Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Jun 2006 00:59:40 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5G0xdQc024040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Jun 2006 20:59:39 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5G0xN3R217988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jun 2006 18:59:23 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5G0xctR009765 for ; Thu, 15 Jun 2006 18:59:38 -0600 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5G0xb4Z009745; Thu, 15 Jun 2006 18:59:38 -0600 Subject: Re: Instrcutions that must not be stepped. From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Daniel Jacobowitz Cc: gdb@sources.redhat.com In-Reply-To: <20060608022654.GA31271@nevyn.them.org> References: <1149726000.10016.71.camel@dufur.beaverton.ibm.com> <20060608022654.GA31271@nevyn.them.org> Content-Type: text/plain Date: Fri, 16 Jun 2006 04:36:00 -0000 Message-Id: <1150415676.3346.30.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00102.txt.bz2 On Wed, 2006-06-07 at 22:26 -0400, Daniel Jacobowitz wrote: > On Wed, Jun 07, 2006 at 05:19:59PM -0700, PAUL GILLIAM wrote: > > Does there currently exist an arch. independent way to detect > > instruction sequences that must not be single stepped? Failing that, is > > there some hook I can use to implement this for just the PowerPC? > > Nope. You'd have to add one. The closer I look at this, the more it looks like a special case of software single step. The difference is that it may not have to be for *every* single step: just those that are trying to step "atomic" sequences. I propose changing the meaning of SOFTWARE_SINGLE_STEP_P () from "This arch has no hardware to do single step and must use software." to "There may be circumstances where this arch will have to do single stepping with out hardware support." And make SOFTWARE_SINGLE_STEP return 1 if a software single step was needed and 0 if it was not. This would require a minor change for those arches currently using SOFTWARE_SINGLE_STEP and a little tweeking in "infrun.c". The only difference between doing a software single step as it is now and doing an "atomic single step" is how the decision of where to place temporary breakpoints is made. > Reading the instruction before stepping is going to slow down single > stepping. Is there some other way we can handle this? I can't think of any way. I did some timing runs, with and without reading the next instruction from the target and in my native ppc64 case, it wasn't too bad. Any way, it would only be a hit on arches that needed it. And if it was real bad, we could let the user decide. -=# Paul #=-