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
next prev parent 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