Re: ARM, registers, "frame 0", where's the PC?

[Torsten Mohr <tmohr at s dot netic dot de>]

Hi,

shame on me, i missed to write some informations.  I thought
i've written it that mail, but obviously i've missed it.

My target is an Atmel EB01 evaluation board (very old one) with
an ARM7TDMI core on it.  I wrote that debugger myself.

It sends out the correct values, i've set R15 to a debug value
0x12345678 ONCE to do some testing.
When i connect to the target, i stop the core, read out the
registers and set R15 to 0x12345678.

After that, GDB asks me for the register values, so i send it
the debug value for R15.
R15 can be ANY value at that time, as no program is yet downloaded
into the target.

GDB then sends me the download data, i program them into the targets
RAM.  GDB then sets R15 to the startup address and says "continue".

That all works fine, the first breakpoint in the beginning of "main"
is caught and the target stops.  GDB asks me for the registers and
i send back THE REAL VALUE for R15, NO DEBUG VALUE, the value is
shown in the registers value and makes sense.  But still GDB says
it stopped at 0x12345678.

I can then continue in GDB, a "c" is sent to the target and it
continues (this works fine).

When i hit the stop button, a "\x03" is sent and the target stops.
GDB then reads out the registers, the real value for R15 is sent,
is shown in the registers value and really makes sense.
But it still says "stopped at 0x12345678".  At the same time,
in the registers window (and in the console output for "info registers")
the real value for R15 is shown.

So R15 is sent to GDB as 0x12345678 only ONCE.  At that time i think
R15 doesn't make any sense, as there's not yet a program in the
target.

Sorry for not writing that before.


Best regards,
Torsten.


> tmohr@s.netic.de said:
> > log: received valid packet 'g', len 1
> > log: wpacket
> > '588e00024854010200100002187800020020000148d4000018680000082e0100605c01
> > 01582e00010f002ce92800dfff3800000100100000d3000040785634120000000000000
> > 00000000000000000000000000000000000000000000000000000000000000000000000
> > 00000000000000000000000000000000000000000000000000000000000000000000000
> > 000000000000000000000000000000000000000000000200000d3'
> > [what's here returned in R15 is always shown as "Program stopped at
> > ADDRESS", no matter what's in R15]
>
> Your remote target seems to be lying to you.  This packet is the registers
> that the target is sending back to gdb.  It's interpreted as:
>
> r0  588e0002
> r1  48540102
> r2  00100002
> r3  18780002
> r4  00200001
> r5  48d40000
> r6  18680000
> r7  082e0100
> r8  605c0101
> r9  582e0001
> r10 0f002ce9
> r11 2800dfff
> r12 38000001
> r13 00100000
> r14 d3000040
> r15 78563412
> f0  000000000000000000000000
> f1  000000000000000000000000
> f2  000000000000000000000000
> f3  000000000000000000000000
> f4  000000000000000000000000
> f5  000000000000000000000000
> f6  000000000000000000000000
> f7  000000000000000000000000
> fpsr 00000000
> cpsr 200000d3
>
> So the value returned to gdb for r15 is (after twidling for endianness)
> 0x12345678 as gdb is reporting.
>
> You need to find out why your remote debug agent is sending a bogus r15
> value.
>
> R.