This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: ARM register pages
- From: "Thomas Rauscher" <trauscher at loytec dot com>
- To: <gdb at sources dot redhat dot com>
- Date: Fri, 10 Jun 2005 11:01:56 +0200
- Subject: RE: ARM register pages
> -----Original Message-----
> From: Richard Earnshaw [mailto:rearnsha@gcc.gnu.org]
> Sent: Friday, June 10, 2005 10:14 AM
> To: Shaun Jackman
> Cc: gdb@sources.redhat.com
> Subject: Re: ARM register pages
>
> On Thu, 2005-06-09 at 22:14, Shaun Jackman wrote:
> > On 6/9/05, Daniel Jacobowitz <drow@false.org> wrote:
> > > The easiest solution will be to do this instead:
> > > abt: [copy the banked address to lr, which is not
> useful at this
> > > point]
> > > 1: b 1b
> >
> > If it's possible, I'd prefer to accomplish a backtrace without
> > altering the target's code. I was hoping that "set $cpsr=0x1f" would
> > make $lr_usr visible in $lr to gdb, but the value of $lr
> displayed by
> > "i reg" remains the same. Does gdb cache the value of the
> register? Is
> > there a way to force gdb to reload the value of the
> register from the
> > remote target?
>
> Be careful. If you set the CPSR to user mode in this way,
> the only way
> back out again will be to take another trap, thus destroying
> any machine
> state you might have. That is, reading the user mode
> registers in this
> way will be destructive to your debugging session.
>
> R.
>
>
A quite simple way to do this is to find the exception handler
and use
set $pc = ...
to set the PC to the 'movs' instruction at the end of the
exception handler. Then issue a single instruction step
si
to return to user mode.
This however skips the exception handler entirely so that
the program would crash most likely when continuing.
Regards,
Thomas Rauscher
--
Thomas Rauscher
LOYTEC electronics GmbH
Stolzenthalergasse 24/3
A-1080 Wien
Austria/Europe
trauscher@loytec.com
www.loytec.com
Phone: +43-1-4020805-15
FAX: +43-1-4020805-99