From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25549 invoked by alias); 16 Jan 2004 14:41:40 -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 25542 invoked from network); 16 Jan 2004 14:41:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Jan 2004 14:41:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AhVAF-0005Vc-EN; Fri, 16 Jan 2004 09:41:35 -0500 Date: Fri, 16 Jan 2004 14:41:00 -0000 From: Daniel Jacobowitz To: Richard.Earnshaw@arm.com Cc: Andrew Cagney , gdb-patches@sources.redhat.com, rearnsha@arm.com Subject: Re: RFA/ARM: Switch mode when setting PC Message-ID: <20040116144135.GA19976@nevyn.them.org> Mail-Followup-To: Richard.Earnshaw@arm.com, Andrew Cagney , gdb-patches@sources.redhat.com, rearnsha@arm.com References: <200401161414.i0GEEud05631@pc960.cambridge.arm.com> <200401161434.i0GEYNe29361@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401161434.i0GEYNe29361@pc960.cambridge.arm.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00412.txt.bz2 On Fri, Jan 16, 2004 at 02:34:23PM +0000, Richard Earnshaw wrote: > > > > > Unless the "Thumb bit" is being stripped out by GDB, then I suspect that > > this is a bug in the gdb/simulator binding layer. Any attempt to force > > the PC value by the debugger should be taken as a potential state change. > > If that is not happening, then all sorts of things may not work. > > > > I've suspected that there is a problem in the way that gdb drives the > > simulator for a while now. > > > > sim_store_register in sim/arm/wrapper.c is currently usring ARMul_SetReg > to set the PC. I think this is wrong. > > RDI_CPUwrite in sim/arm/armrdi.c uses ARMul_SetPC in a similar context. > > ARMul_SetReg should only be used on the PC in specific circumstances, > specifically from within the main simulation loop. Even then it should > probably be using ARMul_SetR15. > > I suspect that this is why several rather gross hacks were introduced over > the years to make single stepping work, and what you are seeing now may be > another artifact of this general problem. OK, but I don't think that's relevant. Take a look at what those functions do: void ARMul_SetR15 (ARMul_State * state, ARMword value) { if (ARMul_MODE32BIT) state->Reg[15] = value & PCBITS; else { state->Reg[15] = value; ARMul_R15Altered (state); } FLUSHPIPE; } void ARMul_SetPC (ARMul_State * state, ARMword value) { if (ARMul_MODE32BIT) state->Reg[15] = value & PCBITS; else state->Reg[15] = R15CCINTMODE | (value & R15PCBITS); FLUSHPIPE; } As I said in my other message, none of these have the potential to switch the simulator from Thumb to ARM mode. I spent some time looking yesterday and I believe that none of the functions used to set the PC do, with the exception of WriteR15Branch; and it's pretty obvious to me that the sim interface should not be using WriteR15Branch, so the simulator's client needs to handle setting the CPSR. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer