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

[Richard Earnshaw]

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.