Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Daniel Jacobowitz <drow@mvista.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:34:00 -0000	[thread overview]
Message-ID: <200401161434.i0GEYNe29361@pc960.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Fri, 16 Jan 2004 14:14:56 GMT." <200401161414.i0GEEud05631@pc960.cambridge.arm.com>


> 
> 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.
> 

sim_store_register in sim/arm/wrapper.c is currently usring ARMul_SetReg 
to set the PC.  I think this is wrong.

RDI_CPUwrite in sim/arm/armrdi.c uses ARMul_SetPC in a similar context.

ARMul_SetReg should only be used on the PC in specific circumstances, 
specifically from within the main simulation loop.  Even then it should 
probably be using ARMul_SetR15.

I suspect that this is why several rather gross hacks were introduced over 
the years to make single stepping work, and what you are seeing now may be 
another artifact of this general problem.

Unfortunately, it may be quite difficult to unwind some of these hacks now 
(I'm not sure all the changes are in the public repository -- someone with 
access to the old Cygnus CVS tree may be able to check, but I certainly 
can't), so the knowledge that there is a problem may not help much in the 
search for a solution :-(

R.


  parent reply	other threads:[~2004-01-16 14:34 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 [this message]
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=200401161434.i0GEYNe29361@pc960.cambridge.arm.com \
    --to=rearnsha@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=cagney@gnu.org \
    --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