From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11758 invoked by alias); 18 Nov 2004 14:26:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11664 invoked from network); 18 Nov 2004 14:26:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 18 Nov 2004 14:26:46 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAIEQfk6012859 for ; Thu, 18 Nov 2004 09:26:41 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAIEQfr05898; Thu, 18 Nov 2004 09:26:41 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 948F2129D8C; Thu, 18 Nov 2004 09:26:34 -0500 (EST) Message-ID: <419CB118.7080401@gnu.org> Date: Thu, 18 Nov 2004 14:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED References: <20041118000159.GG15714@tausq.org> In-Reply-To: <20041118000159.GG15714@tausq.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00373.txt.bz2 Randolph Chung wrote: > Currently only hppa uses this define, but possibly this will be useful > for other architectures which has conditionally nullified instructions > (ia64?) as well. This gets us one step closer to full multiarch > support.. > > Tested on hppa-linux with no regressions. I'm wondering about: # Return non-zero if the processor is executing a delay slot and a # further single-step is needed before the instruction finishes. M::int:single_step_through_delay:struct frame_info *frame:frame and the commented out code: /* If PC is pointing at a nullified instruction, then step beyond it so that the user won't be confused when GDB appears to be ready to execute it. */ /* if (INSTRUCTION_NULLIFIED && currently_stepping (ecs)) */ I suspect that at one stage it was behaving like single_step_through_delay, but was then changed to perform the same operation unconditionally (i.e., when stopping from a cntrl-c say). GDB trying to helpfully do a few extra steps after a cntrl-c bugs me :-) Andrew