From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18775 invoked by alias); 14 Nov 2013 17:19:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 18763 invoked by uid 89); 14 Nov 2013 17:19:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx0a-0014ca01.pphosted.com Received: from Unknown (HELO mx0a-0014ca01.pphosted.com) (208.84.65.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 14 Nov 2013 17:19:50 +0000 Received: from pps.filterd (m0042385.ppops.net [127.0.0.1]) by mx0a-0014ca01.pphosted.com (8.14.5/8.14.5) with SMTP id rAEHCCtM005064; Thu, 14 Nov 2013 09:19:40 -0800 Received: from mx-sanjose.cadence.com (mx-sanjose.Cadence.COM [158.140.2.60]) by mx0a-0014ca01.pphosted.com with ESMTP id 1g46knudf6-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 14 Nov 2013 09:19:40 -0800 Received: from exowa05sj.global.cadence.com (sjmail.Cadence.COM [158.140.32.174]) by mx-sanjose.cadence.com (8.14.4/8.14.4) with ESMTP id rAEHGLur020046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 09:16:21 -0800 (PST) Received: from MAILSJ3.global.cadence.com ([158.140.128.126]) by exowa05sj.global.cadence.com ([158.140.32.66]) with mapi; Thu, 14 Nov 2013 09:19:36 -0800 From: Arnab Bhaduri To: "gdb@sourceware.org" , "mark4th@gmail.com" Date: Thu, 14 Nov 2013 17:19:00 -0000 Subject: RE: back into the thread.... Message-ID: References: In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Received: by mx-sanjose.cadence.com as rAEHGLur020046 at Thu Nov 14 09:16:21 2013 X-SW-Source: 2013-11/txt/msg00068.txt.bz2 Perhaps gdb's attempt to inspect the stack is what is causing the "address = 0" problem ? I would do this: - immediately before stepping the "mov pc, r1" instruction, do "set debug r= emote 1". - this will produce a verbose log of gdb's interaction with the target. - post the log to this thread. Arnab > -----Original Message----- > From: Mark Manning [mailto:mark4th@gmail.com] > Sent: Wednesday, November 13, 2013 4:59 AM > To: Phi Debian > Cc: Sterling Augustine; gdb@sourceware.org > Subject: Re: back into the thread.... >=20 > On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian > wrote: > > On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning > wrote: > >> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian > wrote: > >>> Hi All, > >>> > >>> Off topic about gdb discution > >>> > >> > >> Not off topic if it shows there is a bug in gdb which for the case of > >> embedded arm (maybe only in Gentoo?) i believe there is. > > > > I meant I was doing an off topic answer (not you your post was off > topic. > > > >> the arm processor im running these things on does have an icache and > >> i know enough to clear it even if the person who gave me that code to > >> test forgot that minor detail. > > > > Not so minor ;) > > > > > >> > >> no. i stepi a "mov pc, r1" where r1 points to the new code. > >> immediately after single stepping this opcode im presented with the > >> error message about not being able to access address zero. > >> > >> I know the exact address that r1 was pointing to, it was 0xc000 > >> (which is very easy for a ye olde c64 coder to remember because it > >> was the region of memory at address 49152 that was placed between the > >> kernel and basic roms). > >> > >> Dump the disassembly of where the program counter points to and it > >> exactly what my compiler was supposed to lay down at address 0xc000. > >> There is no opcode misalignment. There are no bogus unimplemented > >> opcodes, the opcodes are exactly what should have been layed down by > >> the compiler given the sources that were fed to it. The program > >> counter also points to address 0xc000. > > > > Again seeing at 0xc000 what you would like to see doesn't mean that > > what you got in your icache. > > > > You could make your dynamic compiler generate few instruction into > > your buffer followed by a tight loop (while(1);) Then continue your > > execution instead of stepi, if whats in the icache is what you expect, > > then it will loop there and you can ^c to confirm, if you still got > > xyz gdb error message, you are not executing what you think you would > > > > Dynamic (self modifiable) code is tricky, look at emacs generated > > lisp, or at the kernel a.out loader code, they basically load buffer > > with data taht will later be executed.... > > > > Cheers, > > Phi >=20 > im 90% certain the icache has been cleared... >=20 > push r0 @ point r0 at where new word starts in code > ldr r2, =3Dold_dp > ldr r0, [r2, #BODY] @ point where new word ends in code > ldr r1, =3Ddp > ldr r1, [r1, #BODY] > str r1, [r2, #BODY] @ new end =3D next start >=20 > movw r7, #2 @ clear icache for selected range > movt r7, #15 > mov r2, #0 > swi 0 > ... >=20 > btw, "dp" in forth is a variable called the dictionary pointer, this > points to the memory where your next piece of compiled code will be > stored. after compiling something the code compiled will lie between old > dp and current dp - the above snippet theoretically clears the icache > between those two memory ranges. >=20 >=20 > -- > "When something can be read without effort, great effort has gone into > its writing." >=20 > -- Enrique Jardiel Poncela --