ARM register pages

ARM register pages

[Shaun Jackman]

Is there an "info registers" command that displays the paged registers
for each ARM mode, such as $lr_svc and $lr_abt? GDB doesn't recognize
these names on the command line for printing/setting. Could this be a
wishlist item?

A "data abort" ARM exception sets the $cpsr to 0x17, the program
counter to 0x10, and the $lr_abt to the previous value of the program
counter. The backtrace command doesn't work now because (I'm guessing)
GDB sees $lr_abt and $sp_abt instead of the $lr_usr and $sp_usr that
contain the useful backtrace information. How can I get a useful
backtrace after a data abort exception?

Thanks,
Shaun

GDB 6.2.1

Re: ARM register pages

[Daniel Jacobowitz]

On Wed, Jun 08, 2005 at 03:00:46PM -0700, Shaun Jackman wrote:
> Is there an "info registers" command that displays the paged registers
> for each ARM mode, such as $lr_svc and $lr_abt? GDB doesn't recognize
> these names on the command line for printing/setting. Could this be a
> wishlist item?

GDB doesn't even know that these registers exist, yet.  The normal ARM
remote protocol doesn't transfer them, either.

> A "data abort" ARM exception sets the $cpsr to 0x17, the program
> counter to 0x10, and the $lr_abt to the previous value of the program
> counter. The backtrace command doesn't work now because (I'm guessing)
> GDB sees $lr_abt and $sp_abt instead of the $lr_usr and $sp_usr that
> contain the useful backtrace information. How can I get a useful
> backtrace after a data abort exception?

GDB doesn't want to do this by default, usually, because they are
likely to be in different executable images.  If they aren't, assuming
that your abort handler saves the banked lr to the stack, you can
write DWARF-2 information to describe where it lives.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: ARM register pages

[Shaun Jackman]

On 6/8/05, Daniel Jacobowitz <drow@false.org> wrote:
> On Wed, Jun 08, 2005 at 03:00:46PM -0700, Shaun Jackman wrote:
> > Is there an "info registers" command that displays the paged registers
> > for each ARM mode, such as $lr_svc and $lr_abt? GDB doesn't recognize
> > these names on the command line for printing/setting. Could this be a
> > wishlist item?
> 
> GDB doesn't even know that these registers exist, yet.  The normal ARM
> remote protocol doesn't transfer them, either.

By the "normal ARM remote protocol" do you mean RDP/RDI, or the GDB
remote protocol for ARM? Does the latter know about these registers?
I'm using a BDI2000 JTAG device which speaks the GDB remote protocol
over Ethernet.

> > A "data abort" ARM exception sets the $cpsr to 0x17, the program
> > counter to 0x10, and the $lr_abt to the previous value of the program
> > counter. The backtrace command doesn't work now because (I'm guessing)
> > GDB sees $lr_abt and $sp_abt instead of the $lr_usr and $sp_usr that
> > contain the useful backtrace information. How can I get a useful
> > backtrace after a data abort exception?
> 
> GDB doesn't want to do this by default, usually, because they are
> likely to be in different executable images.  If they aren't, assuming
> that your abort handler saves the banked lr to the stack, you can
> write DWARF-2 information to describe where it lives.

My data abort handler currently looks like:
	abt: b abt
When everything freezes I interrupt the debugger to look at what's
happened. I'd like to get a backtrace of the user mode from this
state.

Cheers,
Shaun

Re: ARM register pages

[Daniel Jacobowitz]

On Thu, Jun 09, 2005 at 09:46:32AM -0700, Shaun Jackman wrote:
> On 6/8/05, Daniel Jacobowitz <drow@false.org> wrote:
> > On Wed, Jun 08, 2005 at 03:00:46PM -0700, Shaun Jackman wrote:
> > > Is there an "info registers" command that displays the paged registers
> > > for each ARM mode, such as $lr_svc and $lr_abt? GDB doesn't recognize
> > > these names on the command line for printing/setting. Could this be a
> > > wishlist item?
> > 
> > GDB doesn't even know that these registers exist, yet.  The normal ARM
> > remote protocol doesn't transfer them, either.
> 
> By the "normal ARM remote protocol" do you mean RDP/RDI, or the GDB
> remote protocol for ARM? Does the latter know about these registers?

The latter.  RDI does, of course.

> > GDB doesn't want to do this by default, usually, because they are
> > likely to be in different executable images.  If they aren't, assuming
> > that your abort handler saves the banked lr to the stack, you can
> > write DWARF-2 information to describe where it lives.
> 
> My data abort handler currently looks like:
> 	abt: b abt
> When everything freezes I interrupt the debugger to look at what's
> happened. I'd like to get a backtrace of the user mode from this
> state.

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

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: ARM register pages

[Shaun Jackman]

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?

Cheers,
Shaun

Re: ARM register pages

[Daniel Jacobowitz]

On Thu, Jun 09, 2005 at 02:14:11PM -0700, 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?

Oh, you mentioned that you were using 6.2.1.  That might cache the
value of the register.  Try newer.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: ARM register pages

[Daniel Jacobowitz]

On Thu, Jun 09, 2005 at 02:14:11PM -0700, 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?

No, it does not cache it.  You will need to use the "set debug"
commands to work out for yourself what your target is doing; "set debug
remote" is a good one, and the remote protocol is described in the
manual if you aren't familiar with it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: ARM register pages

[Richard Earnshaw]

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.

RE: ARM register pages

[Thomas Rauscher]

  

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