Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Torsten Mohr <tmohr@s.netic.de>
To: gdb <gdb@sources.redhat.com>
Subject: Re: ARM, registers, "frame 0", where's the PC?
Date: Wed, 08 Jan 2003 19:39:00 -0000	[thread overview]
Message-ID: <200301082002.37809.tmohr@s.netic.de> (raw)
In-Reply-To: <200301080413.48695.tmohr@s.netic.de>

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

  reply	other threads:[~2003-01-08 19:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08  3:49 Torsten Mohr
2003-01-08 19:39 ` Torsten Mohr [this message]
2003-01-09  3:31   ` Daniel Jacobowitz
2003-01-09 17:12     ` Torsten Mohr
2003-01-09 17:24       ` Daniel Jacobowitz
2003-01-09 23:23         ` Torsten Mohr
2003-01-09 23:23         ` Torsten Mohr
2003-01-09 23:27           ` Daniel Jacobowitz
2003-01-10  6:52             ` Jan Van Belle
2003-01-10 14:24               ` Daniel Jacobowitz
2003-01-09 12:20   ` Richard Earnshaw
2003-01-09 17:12     ` Torsten Mohr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200301082002.37809.tmohr@s.netic.de \
    --to=tmohr@s.netic.de \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox