From: Richard Earnshaw <rearnsha@arm.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com
Subject: Re: RFA/ARM: Switch mode when setting PC
Date: Sat, 17 Jan 2004 10:49:00 -0000 [thread overview]
Message-ID: <200401171049.i0HAnJ722639@pc960.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Fri, 16 Jan 2004 23:58:43 EST." <20040117045843.GA31115@nevyn.them.org>
> 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.
next prev parent reply other threads:[~2004-01-17 10:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-16 3:54 Daniel Jacobowitz
2004-01-16 5:43 ` Andrew Cagney
2004-01-16 14:10 ` Daniel Jacobowitz
2004-01-16 14:15 ` Richard Earnshaw
2004-01-16 14:26 ` Daniel Jacobowitz
2004-01-16 14:34 ` Richard Earnshaw
2004-01-16 14:41 ` Daniel Jacobowitz
2004-01-16 15:00 ` Richard Earnshaw
2004-01-16 15:56 ` Daniel Jacobowitz
2004-01-16 16:55 ` Richard Earnshaw
2004-01-16 17:11 ` Daniel Jacobowitz
2004-01-16 17:28 ` Richard Earnshaw
2004-01-16 19:12 ` Andrew Cagney
2004-01-16 17:32 ` Daniel Jacobowitz
2004-01-16 18:57 ` Andrew Cagney
2004-01-17 4:58 ` Daniel Jacobowitz
2004-01-17 10:49 ` Richard Earnshaw [this message]
2004-01-17 16:36 ` Andrew Cagney
2004-01-17 16:12 ` Andrew Cagney
2004-01-17 18:54 ` Daniel Jacobowitz
2004-01-17 21:59 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200401171049.i0HAnJ722639@pc960.cambridge.arm.com \
--to=rearnsha@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox