From: Daniel Jacobowitz <drow@mvista.com>
To: Richard.Earnshaw@arm.com
Cc: Andrew Cagney <cagney@gnu.org>,
gdb-patches@sources.redhat.com, rearnsha@arm.com
Subject: Re: RFA/ARM: Switch mode when setting PC
Date: Fri, 16 Jan 2004 14:26:00 -0000 [thread overview]
Message-ID: <20040116142603.GA12836@nevyn.them.org> (raw)
In-Reply-To: <200401161414.i0GEEud05631@pc960.cambridge.arm.com>
On Fri, Jan 16, 2004 at 02:14:56PM +0000, Richard Earnshaw wrote:
> Unless the "Thumb bit" is being stripped out by GDB, then I suspect that
> this is a bug in the gdb/simulator binding layer. Any attempt to force
> the PC value by the debugger should be taken as a potential state change.
> If that is not happening, then all sorts of things may not work.
>
> I've suspected that there is a problem in the way that gdb drives the
> simulator for a while now.
My understanding of the ARM architecture is of somewhat recent vintage,
so the following may be a load of crap. For unrelated reasons I can't
test this in hardware yet.
The bx instruction sets the PC register to reg & 0xfffffffe. It uses
reg & 0x1 to set the T bit. So the value that gets written into the PC
register has its low bit clear, and the CPSR gets updated. The low bit
of the actual PC register is ignored. Isn't that correct?
If so, I think the interface is fine. Certainly it corresponds to how
ptrace behaves on Linux; the value specified for the PC is written
directly to the PC, not parsed for the T bit. If you want to change
the T bit, write to the CPSR.
Right now the address of a Thumb function is marked in the symbol table
by the msymbol "special" flag, not in the low bit of the address. The
address points at the actual beginning of the instruction, so that's
what GDB writes into $pc.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2004-01-16 14:26 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 [this message]
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
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=20040116142603.GA12836@nevyn.them.org \
--to=drow@mvista.com \
--cc=Richard.Earnshaw@arm.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=rearnsha@arm.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