From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30164 invoked by alias); 16 Jan 2004 15:56:46 -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 30157 invoked from network); 16 Jan 2004 15:56:45 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Jan 2004 15:56:45 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AhWKv-00082n-V1; Fri, 16 Jan 2004 10:56:41 -0500 Date: Fri, 16 Jan 2004 15:56: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: <20040116155641.GA30811@nevyn.them.org> Mail-Followup-To: Richard.Earnshaw@arm.com, Andrew Cagney , gdb-patches@sources.redhat.com, rearnsha@arm.com References: <20040116144135.GA19976@nevyn.them.org> <200401161459.i0GExws07052@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401161459.i0GExws07052@pc960.cambridge.arm.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00414.txt.bz2 On Fri, Jan 16, 2004 at 02:59:58PM +0000, Richard Earnshaw wrote: > Sure, but I think that is just more lossage that has been introduced after > the ARMulator was released by ARM. Remember that the code that was > released didn't have any Thumb support at all, that has all been added at > a later date. So the fact that ARMul_SetPC doesn't correctly update the OK, I didn't know that. > Thumb bit is also a bug. There's no reason why it shouldn't (and, AFAICT, > every reason why it should). Then it would be possible to execute an > image where even the first instruction was in Thumb state. It's already possible; you have to set the CPSR by hand, though. Am I missing something? > So, I still think that wrapper.c should be using ARMul_SetPC to update > R15, which should then be correctly managing the Thumb bit in the CPSR. > Note that ARMul_SetPC is only called from wrapper.c and armrdi.c, the two > interfaces to the simulator. So there's no chance that fixing this will > break normal free-running simulation. > > However, there are other changes (hacks) in the main loop that were > introduced to overcome the fact that ARMul_SetPC wasn't being used, these > may have to be tracked down and fixed. I guess I just see this differently. The existing Linux ptrace interface also predates Thumb, so it's not surprising that it just writes what you give it into the PC register. But I can't see any reason why I should change that. The remote protocol is a very low-level protocol; the CPSR and PC are separate writeable registers, and I would find it extremely surprising if the sequence: read CPSR read PC write PC read CPSR could return two different CPSR values. Here's what I would find even more surprising. The sequence: read PC write same value to PC would suddenly switch me out of Thumb mode, since the bit is cleared in the PC! This would break _all_ uses of the interface (either the sim interface or the ptrace interface) in Thumb mode. Right now there are only problems if you are deliberately trying to mode switch. In short, I think writing the PC should not change the CPSR, and if the client wants to change the mode they should do it explicitly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer