From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11288 invoked by alias); 16 Jan 2004 16:55:08 -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 11281 invoked from network); 16 Jan 2004 16:55:06 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 16 Jan 2004 16:55:06 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id i0GGsUAO003931; Fri, 16 Jan 2004 16:54:30 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i0GGsU211548; Fri, 16 Jan 2004 16:54:30 GMT Message-Id: <200401161654.i0GGsU211548@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: Richard.Earnshaw@arm.com, Andrew Cagney , gdb-patches@sources.redhat.com, rearnsha@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: RFA/ARM: Switch mode when setting PC In-reply-to: Your message of "Fri, 16 Jan 2004 10:56:41 EST." <20040116155641.GA30811@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 2004 16:55:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-01/txt/msg00416.txt.bz2 > 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. You raise an interesting point. I'd been thinking about it purely from the simulator's perspective, rather than in the wider context. I've just had a conversation with some engineers in our debugger group to see if there was a specific opinion. The consensus seems to be that you are right, the debugger must correctly set the 'CPSR' if it wants the inferior to switch states. All this means that there are effectively 33 bits that have to be updated when the PC is written and a state change is needed. This is complicated further by the fact that sometimes one of those bits needs to be manufactured, and at other times it doesn't. (in fact, there can be 34 bits if you include the CPSR 'J' bit, but let's not even think about going there). For example, if the user writes a 32-bit value into the PC, the CPSR state probably shouldn't be changed (even if the bottom bit is altered) -- this is how ARM's debuggers behave. However, if the user 'calls' a function that is in the 'other state', then the CPSR should be updated (and presumably restored afterwards). I'm not sure if GDB has a way of separating these two cases. It's an interesting problem. As a final comment, when it comes to talking directly to real hardware (eg, via an ICE box), it isn't generally possible to update the CPSR by just writing to it (at least, not for the 'T' and 'J' bits); the only way of switching to Thumb state is via a BX instruction or with some other PC-modifying instruction that is documented to cause a state change (on ARMv4T that normally means 'movs PC, ...' or 'ldm ..., PC}^'; on v5 some loads to the PC can also be used). R.