From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17094 invoked by alias); 17 Jan 2004 10:49: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 17080 invoked from network); 17 Jan 2004 10:49:50 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 17 Jan 2004 10:49:50 -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 i0HAnJAO011964; Sat, 17 Jan 2004 10:49:19 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i0HAnJ722639; Sat, 17 Jan 2004 10:49:19 GMT Message-Id: <200401171049.i0HAnJ722639@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: gdb-patches@sources.redhat.com, Richard.Earnshaw@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 23:58:43 EST." <20040117045843.GA31115@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jan 2004 10:49:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-01/txt/msg00434.txt.bz2 > On Fri, Jan 16, 2004 at 02:12:18PM -0500, Andrew Cagney wrote: > > Or a lack of design, Arm needs to ensure that it doesn't define PC_REGNUM. > > OK, I'll keep that in mind. > > > >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. > > Perhaps, in that case, we should have the PC as a pseudoregister. That > would simplify a lot of arm-tdep.c. That was my feeling too. > Is it possible to use the existing > ARM compiler and simulator (and newlib) in 26-bit mode without a lot of > hassle, or would it be the work of months to make it happen? I'm > reluctant to dig my fingers in too deeply if I can't test both code > paths. It should be possible. At least, it used to be possible. In GDB you should be able to do set arm apcs32 off and then you should get the debugger to think it is talking to a 26-bit mode host. I doubt the code has been tested much recently. In fact, I want to deprecate support for compiling 26-bit mode code in gcc fairly soon -- but that isn't quite the same thing as deprecating 26-bit mode execution; a processor running in 26-bit mode can generally run apcs32 code as long as certain rare sequences are avoided. R.