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

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

[Torsten Mohr]

Hi,

i received a hint by mail to send ALL registers from the
GDB remote protocol server back to arm-unknown-elf-insight.

I now do that but it i still get this unwanted behaviour:

I can download a program, start it, stop it, read registers
(the correct values are shown, as i see in the debug output
of my debug server).  The values make sense, R15 is exactly
where i expect it to be.

But when i stop the program, "insight" tells me that it
stopped at 0x01002048.  That's nowhere in my program
and not what's shown in R15.

In the GDB console, "info registers" shows the same values
as in "insight".  Especially "p/x $pc" says 0x02020070
what makes sense and is correct.

In "info gdb" i read:

   Normally, register values are relative to the selected stack frame
(*note Selecting a frame: Selection.).  This means that you get the
value that the register would contain if all stack frames farther in
were exited and their saved registers restored.  In order to see the
true contents of hardware registers, you must select the innermost
frame (with `frame 0').

When i type "frame 0", gdb says:
gdb) frame 0
#0  0x01002048 in ?? ()

This seems to be related to the problem.  I have to admit i don't
understand that.  Why can't GDB say where it stopped, it has the
correct value for R15.  Also, inbetween the stop ("\x03") and the
reading of the registers ("g") there is no other request from
GDB.  What info is missing?


Thanks for any hints,
Torsten.

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

[Torsten Mohr]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

Hi,

i found out by testing that the first time i stop the target
and read out its registers, the value of R15 is used in the
message "Program stopped at 0x12345678".

When i type in GDB:
(gdb) info frame
Stack level 0, frame at 0x1000:
 pc = 0x12345678; saved pc 0x20203a8
 (FRAMELESS), called by frame at 0x1000
 Arglist at 0x1000, args: 
 Locals at 0x1000, Previous frame's sp in sp

Could these problems be related to the structures on the
stack?  When i set R15 to 0x0000 the first time i
read out the registers, i get the message "Program stopped
at 0x00000000".  What can i do to tell GDB to use the
real value in R15?

I appended a log file of a session, all requests and answers
are in there.  Is any of the answers not correct?

Could this be related to the startup code of the test program?
I attached it to this mail.


It would be great if anybody had a hint for me.


Best regards,
Torsten.


> Hi,
>
> i received a hint by mail to send ALL registers from the
> GDB remote protocol server back to arm-unknown-elf-insight.
>
> I now do that but it i still get this unwanted behaviour:
>
> I can download a program, start it, stop it, read registers
> (the correct values are shown, as i see in the debug output
> of my debug server).  The values make sense, R15 is exactly
> where i expect it to be.
>
> But when i stop the program, "insight" tells me that it
> stopped at 0x01002048.  That's nowhere in my program
> and not what's shown in R15.
>
> In the GDB console, "info registers" shows the same values
> as in "insight".  Especially "p/x $pc" says 0x02020070
> what makes sense and is correct.
>
> In "info gdb" i read:
>
>    Normally, register values are relative to the selected stack frame
> (*note Selecting a frame: Selection.).  This means that you get the
> value that the register would contain if all stack frames farther in
> were exited and their saved registers restored.  In order to see the
> true contents of hardware registers, you must select the innermost
> frame (with `frame 0').
>
> When i type "frame 0", gdb says:
> gdb) frame 0
> #0  0x01002048 in ?? ()
>
> This seems to be related to the problem.  I have to admit i don't
> understand that.  Why can't GDB say where it stopped, it has the
> correct value for R15.  Also, inbetween the stop ("\x03") and the
> reading of the registers ("g") there is no other request from
> GDB.  What info is missing?
>
>
> Thanks for any hints,
> Torsten.

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 6203 bytes --]

accepting ...
log: request from '127.0.0.1'

log: discarded '+'
log: received valid packet 'Hc-1', len 4
[stopping the core]
     REG        USR        FIQ        SVC        ABT        IRQ        UND        SYS
CPSR 200000d3   200000d0   200000d1   200000d3   200000d7   200000d2   200000db   200000df

R0   02008e58   02008e58
R1   02015448   02015448
R2   02001000   02001000
R3   02007818   02007818
R4   01002000   01002000
R5   0000d448   0000d448
R6   00006818   00006818
R7   00012e08   00012e08
R8   01015c60   01015c60   00000000
R9   01002e58   01002e58   00000000
R10  e92d000f   e92d000f   00000000
R11  ffe00028   ffe00028   00000000
R12  01000038   01000038   00000000
R13  00001000   02000cf8   02000400   00001000   00000000   02000500   02000e00   02000cf8
R14  400000d3   02014c9c   00000000   400000d3   01002204   020144c4   00000000   02014c9c
R15  01002048   01002048
log: wpacket 'OK'


log: received valid packet 'qC', len 2
log: wpacket ''


log: received valid packet 'qOffsets', len 8
log: wpacket ''


log: received valid packet '?', len 1
log: wpacket 'S00'


log: received valid packet 'Hg0', len 3
log: wpacket 'OK'


log: received valid packet 'g', len 1
log: wpacket '588e00024854010200100002187800020020000148d4000018680000082e0100605c0101582e00010f002ce92800dfff3800000100100000d30000407856341200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000d3'
[what's here returned in R15 is always shown as "Program stopped at ADDRESS", no matter what's in R15]


[why does GDB read out these addresses ?]
log: received valid packet 'm12e08,4', len 8
log: wpacket '000a0201'


log: received valid packet 'm10209f8,4', len 10
log: wpacket 'ff04ffff'


log: received valid packet 'X2020000,0:', len 11
log: wpacket ''

[download of program]
log: received valid packet 'M2020000,9f:0dc0a0e100d82de904b04ce204d04de210000be500a81be90dc0a0e100d82de904b04ce200a81be90dc0a0e100d82de904b04ce200a81be90dc0a0e100d82de904b04ce20000a0e1cc209fe50030a0e3003082e5c0309fe5002093e5273ca0e30f3083e2030052e1000000da050000eaa4209fe5a0309fe5003093e5013083e2003082e5f2ffffea90209fe58c309fe5003093e5013083e2003082e57c309f', len 330
log: wpacket 'OK'
log: received valid packet 'M202009f,9f:e5003093e5013003e2000053e30400000aff3ce0e3cf3043e20220a0e3002083e5030000eaff3ce0e3cb3043e20220a0e3002083e5cfffffeb40309fe5003093e5023003e2000053e30400000aff3ce0e3cf3043e20420a0e3002083e5030000eaff3ce0e3cb3043e20420a0e3002083e5bd0000ebc3ffffebcaffffea1c040202200402020dc0a0e100d82de904b04ce2ff3ce0e3ef3043e20620a0e30020', len 330
log: wpacket 'OK'
log: received valid packet 'M202013e,9f:83e5ff3ce0e3cf3043e20620a0e3002083e5e0219fe50030a0e3003082e5d8219fe50030a0e3003082e5d0219fe50030a0e3003082e5afffffeb950000ebc0019fe59e0000ebbc219fe50030a0e3003082e5b0319fe5002093e5273ca0e30f3083e2030052e1000000da050000ea94219fe590319fe5003093e5013083e2003082e5f2ffffea70219fe56c319fe5003093e5013083e2003082e5780000eb00', len 330
log: wpacket 'OK'
log: received valid packet 'M20201dd,9f:30a0e1000053e31400000a790000eb0020a0e154319fe5002083e538219fe534319fe5003093e5013083e2003082e52c319fe5003093e5000053e30700001a1c219fe50130a0e3003082e520219fe518319fe5003093e5043083e2003082e5680000ebff3ce0e3c33043e2003093e5203003e2000053e30600000ae4009fe5670000ebd0209fe5cc309fe5003093e5013083e2003082e5ff3ce0e3c33043e2', len 330
log: wpacket 'OK'
log: received valid packet 'M202027c,9f:003093e5023c03e2000053e30d00000a500000eb0020a0e1b0309fe5002083e5a8309fe5003093e5610053e30000001a61ffffeb80209fe57c309fe5003093e5013083e2003082e56c309fe5003093e5013003e2000053e30400000aff3ce0e3cf3043e20220a0e3002083e5030000eaff3ce0e3cb3043e20220a0e3002083e534309fe5003093e5023003e2000053e30400000aff3ce0e3cf3043e20420a0', len 330
log: wpacket 'OK'
log: received valid packet 'M202031b,9f:e3002083e597ffffeaff3ce0e3cb3043e20420a0e3002083e592ffffea20040202240402022c040202785634121c040202280402023004020200000fe100400fe1fcffffea54009fe500d0a0e100b0a0e10700a0e30810a0e30920a0e30a30a0e30b40a0e30c50a0e30d60a0e30e70a0e30f80a0e31090a0e311a0a0e312b0a0e313c0a0e314d0a0e35effffeb0000a0e10000a0e1fdffffea0ef0a0e12401', len 330
log: wpacket 'OK'
log: received valid packet 'M20203ba,62:020200e00202100e10ee010000e20030a0e10770a0e10ef0a0e1100e11ee0030a0e10990a0e10ef0a0e10c00a0e3100e10ee020000e2020020e20030a0e10aa0a0e10ef0a0e1100e01ee0ef0a0e133cc55aa0dc0a0e100d82de904b04ce200a81be9', len 208
log: wpacket 'OK'
log: received valid packet 'Pf=60030202', len 11
log: wpacket 'OK'
log: received valid packet 'Z0,2020130,4', len 12
log: wpacket 'OK'


log: received valid packet 'Hc0', len 3
log: wpacket 'OK'


log: received valid packet 'c', len 1
log: starting due to 'c'
START, 0x02020360
setting HW breakpoint at 0x02020130
     REG        USR        FIQ        SVC        ABT        IRQ        UND        SYS
CPSR 00000053   00000050   00000051   00000053   00000057   00000052   0000005b   0000005f

R0   00000007   00000007
R1   00000008   00000008
R2   00000009   00000009
R3   0000000a   0000000a
R4   0000000b   0000000b
R5   0000000c   0000000c
R6   0000000d   0000000d
R7   0000000e   0000000e
R8   0000000f   0000000f   00000000
R9   00000010   00000010   00000000
R10  00000011   00000011   00000000
R11  00000010   00000010   00000000
R12  00000014   00000014   00000000
R13  00000004   02000cf8   02000400   00000004   00000000   02000500   02000e00   02000cf8
R14  020203a8   02014c9c   00000000   020203a8   01002204   020144c4   00000000   02014c9c
R15  02020134   02020134
log: wpacket 'S0'


log: received valid packet 'g', len 1
log: wpacket '0700000008000000090000000a0000000b0000000c0000000d0000000e0000000f0000001000000011000000100000001400000004000000a8030202340102020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000053'


log: received valid packet 'm0,4', len 4
log: wpacket '060000ff'


log: received valid packet 'm2020360,4', len 10
log: wpacket '5400ffff'


log: received valid packet 'm0,4', len 4
log: wpacket '060000ff'

[-- Attachment #3: start.s --]
[-- Type: text/plain, Size: 518 bytes --]

	.section	.text
	.global		_start
	.global		stackTop
	.global		__gccmain

here:
	mrs		r0, cpsr
	mrs		r4, cpsr
	b		here

_start:

	ldr		r0,_stackTop
	mov		sp,r0
	mov		fp,r0

	mov		r0, #0x07
	mov		r1, #0x08
	mov		r2, #0x09
	mov		r3, #0x0a
	mov		r4, #0x0b
	mov		r5, #0x0c
	mov		r6, #0x0d
	mov		r7, #0x0e
	mov		r8, #0x0f
	mov		r9, #0x10
	mov		r10, #0x11
	mov		r11, #0x12
	mov		r12, #0x13
	mov		r13, #0x14
#	b		here

	bl		main
	nop
end:
	nop
	b		end

__gccmain:
	mov		pc,lr

_main:
	.word		main

_stackTop:
	.word		stackTop

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

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 08:02:37PM +0100, Torsten Mohr wrote:
> Hi,
> 
> i found out by testing that the first time i stop the target
> and read out its registers, the value of R15 is used in the
> message "Program stopped at 0x12345678".
> 
> When i type in GDB:
> (gdb) info frame
> Stack level 0, frame at 0x1000:
>  pc = 0x12345678; saved pc 0x20203a8
>  (FRAMELESS), called by frame at 0x1000
>  Arglist at 0x1000, args: 
>  Locals at 0x1000, Previous frame's sp in sp
> 
> Could these problems be related to the structures on the
> stack?  When i set R15 to 0x0000 the first time i
> read out the registers, i get the message "Program stopped
> at 0x00000000".  What can i do to tell GDB to use the
> real value in R15?
> 
> I appended a log file of a session, all requests and answers
> are in there.  Is any of the answers not correct?
> 
> Could this be related to the startup code of the test program?
> I attached it to this mail.

Could you show me the log via 'set debug remote 1' instead?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

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

[Torsten Mohr]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

Hi,

> Could you show me the log via 'set debug remote 1' instead?

i've attached the output to this mail, so the lines are not broken.
Would it make sense to send some more files/infos?


Best regards,
Torsten.

[-- Attachment #2: arm --]
[-- Type: text/plain, Size: 5687 bytes --]

(gdb) set debug remote 1
[I hit RUN]
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: 
Sending packet: $qOffsets#4b...Ack
Packet received: Text=00;Data=00;Bss=00
Sending packet: $?#3f...Ack
Packet received: S00
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 348d00024854010200100002187800020020000148d40000186800002c2f0100605c0101342d000170a81ae92800dfff3800000100100000d30000407856341200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000d3
Sending packet: $m12f2c,4#2b...Ack
Packet received: 00040200
Sending packet: $m203f8,4#00...Ack
Packet received: 00200000
0x12345678 in ?? ()
Loading section .text, size 0x3e4 lma 0x2020000
Sending packet: $X2020000,0:#42...Ack
Packet received: 
binary downloading NOT suppported by target
Sending packet: $M2020000,9f:0dc0a0e100d82de904b04ce204d04de210000be500a81be90dc0a0e100d82de904b04ce200a81be90dc0a0e100d82de904b04ce200a81be90dc0a0e100d82de904b04ce20000a0e1cc209fe50030a0e3003082e5c0309fe5002093e5273ca0e30f3083e2030052e1000000da050000eaa4209fe5a0309fe5003093e5013083e2003082e5f2ffffea90209fe58c309fe5003093e5013083e2003082e57c309f#3b...Ack
Packet received: OK
Sending packet: $M202009f,9f:e5003093e5013003e2000053e30400000aff3ce0e3cf3043e20220a0e3002083e5030000eaff3ce0e3cb3043e20220a0e3002083e5cfffffeb40309fe5003093e5023003e2000053e30400000aff3ce0e3cf3043e20420a0e3002083e5030000eaff3ce0e3cb3043e20420a0e3002083e5af0000ebc3ffffebcaffffeae4030202e80302020dc0a0e100d82de904b04ce2ff3ce0e3ef3043e20620a0e30020#1b...Ack
Packet received: OK
Sending packet: $M202013e,9f:83e5ff3ce0e3cf3043e20620a0e3002083e5e0219fe50030a0e3003082e5d8219fe50030a0e3003082e5d0219fe50030a0e3003082e5afffffeb870000ebc0019fe5900000ebbc219fe50030a0e3003082e5b0319fe5002093e5273ca0e30f3083e2030052e1000000da050000ea94219fe590319fe5003093e5013083e2003082e5f2ffffea70219fe56c319fe5003093e5013083e2003082e56a0000eb00#66...Ack
Packet received: OK
Sending packet: $M20201dd,9f:30a0e1000053e31400000a6b0000eb0020a0e154319fe5002083e538219fe534319fe5003093e5013083e2003082e52c319fe5003093e5000053e30700001a1c219fe50130a0e3003082e520219fe518319fe5003093e5043083e2003082e55a0000ebff3ce0e3c33043e2003093e5203003e2000053e30600000ae4009fe5590000ebd0209fe5cc309fe5003093e5013083e2003082e5ff3ce0e3c33043e2#30...Ack
Packet received: OK
Sending packet: $M202027c,9f:003093e5023c03e2000053e30d00000a420000eb0020a0e1b0309fe5002083e5a8309fe5003093e5610053e30000001a61ffffeb80209fe57c309fe5003093e5013083e2003082e56c309fe5003093e5013003e2000053e30400000aff3ce0e3cf3043e20220a0e3002083e5030000eaff3ce0e3cb3043e20220a0e3002083e534309fe5003093e5023003e2000053e30400000aff3ce0e3cf3043e20420a0#d9...Ack
Packet received: OK
Sending packet: $M202031b,a0:e3002083e597ffffeaff3ce0e3cb3043e20420a0e3002083e592ffffeae8030202ec030202f403020278563412e4030202f0030202f803020228009fe500d0a0e100b0a0e10dc0a0e100d82de904b04ce26cffffeb0000a0e10000a0e1fdffffea0ef0a0e12401020200e00202100e10ee010000e20030a0e10770a0e10ef0a0e1100e11ee0030a0e10990a0e10ef0a0e10c00a0e3100e10ee020000e2020020#61...Ack
Packet received: OK
Sending packet: $M20203bb,29:e20030a0e10aa0a0e10ef0a0e1100e01ee0ef0a0e133cc55aa0dc0a0e100d82de904b04ce200a81be9#8c...Ack
Packet received: OK
Start address 0x2020354, load size 996
Sending packet: $Pf=54030202#83...Ack
Packet received: OK
Transfer rate: 1593 bits/sec, 142 bytes/write.
Sending packet: $Z0,2020130,4#6e...Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: S0
Sending packet: $g#67...Ack
Packet received: 00e002024854010200100002187800020020000148d40000186800002c2f0100605c0101342d000170a81ae9ecdf0202f0df0202e0df020270030202340102020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013
Sending packet: $m0,4#fd...Ack
Packet received: 060000ff
Sending packet: $m2020354,4#2d...Ack
Packet received: 2800ffff
Sending packet: $c#63...Ack

(gdb) info registers
Error: The debugger is busy.
[I hit STOP in INSIGHT]
remote_stop called
Packet received: S0
Sending packet: $g#67...Ack
Packet received: 00e0020248540102e4030202651a00000020000148d40000186800002c2f0100605c0101342d000170a81ae9dcdf0202d0df0202d0df020218010202540002020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000013
Sending packet: $m2020038,4#2c...Ack
Packet received: 0dffffff

(gdb) info registers
r0             0x202e000	33742848
r1             0x2015448	33641544
r2             0x20203e4	33686500
r3             0x1a65	6757
r4             0x1002000	16785408
r5             0xd448	54344
r6             0x6818	26648
r7             0x12f2c	77612
r8             0x1015c60	16866400
r9             0x1002d34	16788788
r10            0xe91aa870	-384128912
r11            0x202dfdc	33742812
r12            0x202dfd0	33742800
sp             0x202dfd0	33742800
lr             0x2020118	33685784
pc             0x2020054	33685588
fps            0x0	0
cpsr           0x13000080	318767232

(gdb) info frame
Stack level 0, frame at 0x1000:
 pc = 0x12345678; saved pc 0x2020118
Sending packet: $m0,4#fd...Ack
Packet received: 060000ff
 (FRAMELESS), called by frame at 0x1000
 Arglist at 0x1000, args: 
 Locals at 0x1000, Previous frame's sp in sp

(gdb) 

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

[Torsten Mohr]

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.

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

[Daniel Jacobowitz]

On Thu, Jan 09, 2003 at 05:36:01PM +0100, Torsten Mohr wrote:
> Hi,
> 
> > Could you show me the log via 'set debug remote 1' instead?
> 
> i've attached the output to this mail, so the lines are not broken.
> Would it make sense to send some more files/infos?

Have you tried this without using Insight?  It looks to me like
something's not flushing the frame cache that ought to be.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Torsten Mohr]

Hi,

> Have you tried this without using Insight?  It looks to me like
> something's not flushing the frame cache that ought to be.

No, not yet.  I'm not an experienced gdb user.  I think i have
to find out the commands i have to use before...
But this is the next thing i'll do, i even thought it would
be safer to use insight, as it would choose the right commands.

Should i post the log file on the insight mailing list too?


Best regards,
Torsten.

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

[Torsten Mohr]

Hi,

> Have you tried this without using Insight?  It looks to me like
> something's not flushing the frame cache that ought to be.

i just did some more testing, it seems it disturbed GDB and INSIGHT
that it is not ok to answer a "continue" with a "S0" after the
target stopped again.  I now use a "S00", which improves things
a lot.  Yes, i just doublechecked that, when the target stops
after a "continue" and i send "S0", it tells me it stopped at
0x12345678, when i answer "S00", insight shows me where it stopped
in the window.  Looking at "info gdb" this is specified, so
it is my mistake.  I took that information from a file i found
in the web where it didn't state that S<signal> has to be
S<%02-Signal>.  Maybe gdb/insight throws the answer "S0" away
and just ignores it and uses its last informations?


But anyway, when i answer "S00" there's a popup window every
time i stop.  Looking at "info gdb", i'd say an answer with
"S" is preferred before "W", "X" or "T".
Looking at "man -S 7 signal" i'm confused and don't know
what signal number to use.

"W00": program exited normally
"X00": program exited with signal 0, Signal 0
"T00": program received signal 0, Signal 0

"S": doesn't work, same problem as before.

So i guess there has to be a certain number that doesn't bring
up that window/message.

"S01": SIGHUP
"S11": SIGSTOP
"OK": doesn't work, insight hangs.


Hmm, don't know, what could the preferred answer be?


Best regards,
Torsten.

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

[Daniel Jacobowitz]

On Thu, Jan 09, 2003 at 11:46:45PM +0100, Torsten Mohr wrote:
> Hi,
> 
> > Have you tried this without using Insight?  It looks to me like
> > something's not flushing the frame cache that ought to be.
> 
> i just did some more testing, it seems it disturbed GDB and INSIGHT
> that it is not ok to answer a "continue" with a "S0" after the
> target stopped again.  I now use a "S00", which improves things
> a lot.  Yes, i just doublechecked that, when the target stops
> after a "continue" and i send "S0", it tells me it stopped at
> 0x12345678, when i answer "S00", insight shows me where it stopped
> in the window.  Looking at "info gdb" this is specified, so
> it is my mistake.  I took that information from a file i found
> in the web where it didn't state that S<signal> has to be
> S<%02-Signal>.  Maybe gdb/insight throws the answer "S0" away
> and just ignores it and uses its last informations?
> 
> 
> But anyway, when i answer "S00" there's a popup window every
> time i stop.  Looking at "info gdb", i'd say an answer with
> "S" is preferred before "W", "X" or "T".
> Looking at "man -S 7 signal" i'm confused and don't know
> what signal number to use.
> 
> "W00": program exited normally
> "X00": program exited with signal 0, Signal 0
> "T00": program received signal 0, Signal 0
> 
> "S": doesn't work, same problem as before.
> 
> So i guess there has to be a certain number that doesn't bring
> up that window/message.
> 
> "S01": SIGHUP
> "S11": SIGSTOP
> "OK": doesn't work, insight hangs.
> 
> 
> Hmm, don't know, what could the preferred answer be?

05, SIGTRAP.  You should really look at existing stubs.  You probably
want to be using T anyway.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jan Van Belle]

Daniel Jacobowitz wrote:

> 
> 05, SIGTRAP.  You should really look at existing stubs.  You probably
> want to be using T anyway.

I've been struggling with this too. Anyway, I only use the S
command. I think it's
the simplest way to do something when first implementing an
interface. T implies you 
support threads, thus supporting most of the
'thread-related' commands.

Kind regards,

Jan

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

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 07:52:21AM +0100, Jan Van Belle wrote:
> Daniel Jacobowitz wrote:
> 
> > 
> > 05, SIGTRAP.  You should really look at existing stubs.  You probably
> > want to be using T anyway.
> 
> I've been struggling with this too. Anyway, I only use the S
> command. I think it's
> the simplest way to do something when first implementing an
> interface. T implies you 
> support threads, thus supporting most of the
> 'thread-related' commands.

No, it doesn't; it only provides a way to reply with registers
efficiently at the stop.  GDB won't assume threads support.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer