From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30919 invoked by alias); 16 Jan 2004 17:28:33 -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 30903 invoked from network); 16 Jan 2004 17:28:32 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 16 Jan 2004 17:28:32 -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 i0GHRxAO006371; Fri, 16 Jan 2004 17:27:59 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i0GHRxt24387; Fri, 16 Jan 2004 17:27:59 GMT Message-Id: <200401161727.i0GHRxt24387@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 12:11:20 EST." <20040116171120.GA6374@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 2004 17:28:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-01/txt/msg00418.txt.bz2 > > The consensus seems to be that you are right, the debugger must correctly > > set the 'CPSR' if it wants the inferior to switch states. > > Patch OK then? > I'm happy with the ARM part, if you can convince Andrew that the MI part is ok. > > 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. > > I believe that this will work at present, because setting $pc will not > go through write_pc. There's some blind luck involved in this, though. In the past we've tried to distinguish R15 from PC. This was especially useful in the legacy 26-bit mode where the CPSR bits *were* in R15. This would probably all have been much simpler if I'd been able to complete my code for handling the banked register; sadly I never got far enough, and I think the code is probably too bit-rotten to be worth trying to resurrect directly at this point. > > > 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). > > Really? Interesting... I don't think GDB handles this at all at the > moment. For both Linux userland GDB and Linux remote kernel GDB, this > is a non-issue; you can write the CPSR directly and it will be restored > at return from exception (via the SPSR and an ldm instruction). This > works because the kgdb stub is implemented as an exception handler. If you are talking directly to a core through a hardware channel such as an ICE, there's all sorts of restrictions and limitations. It's usually the job of a further layer to map the high(ish)-level directives from the debugger onto commands that can be done on the target (in many instances you have to insert instructions directly into the core pipeline -- well the fetch unit -- and then clock them through). It's not an area I know much about beyond the very basics. R.