From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Received: (qmail 23504 invoked from network); 9 Jan 2003 17:12:56 -0000 Received: from unknown (HELO mail.s.netic.de) (212.9.160.11) by 209.249.29.67 with SMTP; 9 Jan 2003 17:12:56 -0000 Received: from isdn052.s.netic.de ([212.9.162.52] helo=schleim.qwe.de) by mail.s.netic.de with esmtp (Exim 4.10) id 18WgES-0000uf-00; Thu, 09 Jan 2003 18:12:41 +0100 Received: from schleim (localhost [127.0.0.1]) by schleim.qwe.de (Postfix) with ESMTP id 9C954D4F; Thu, 9 Jan 2003 17:27:41 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Torsten Mohr To: Richard.Earnshaw@arm.com, Richard Earnshaw Subject: Re: ARM, registers, "frame 0", where's the PC? Date: Thu, 09 Jan 2003 17:12:00 -0000 User-Agent: KMail/1.4.3 Cc: gdb , Richard.Earnshaw@arm.com References: <200301091220.h09CK5s22668@pc960.cambridge.arm.com> In-Reply-To: <200301091220.h09CK5s22668@pc960.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301091727.41440.tmohr@s.netic.de> X-SW-Source: 2003-01/txt/msg00134.txt.bz2 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.