This is the mail archive of the
mailing list for the GDB project.
RE: back into the thread....
- From: Arnab Bhaduri <arnab at cadence dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>, "mark4th at gmail dot com" <mark4th at gmail dot com>
- Date: Thu, 14 Nov 2013 09:19:35 -0800
- Subject: RE: back into the thread....
- Authentication-results: sourceware.org; auth=none
- References: <CAPGNrUUAaRjEgxj3j4DB3sFbzR2-GHPKjFD9jSeKOdpJy_Qmig at mail dot gmail dot com>
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 remote 1".
- this will produce a verbose log of gdb's interaction with the target.
- post the log to this thread.
> -----Original Message-----
> From: Mark Manning [mailto:firstname.lastname@example.org]
> Sent: Wednesday, November 13, 2013 4:59 AM
> To: Phi Debian
> Cc: Sterling Augustine; email@example.com
> Subject: Re: back into the thread....
> On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian <firstname.lastname@example.org>
> > On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning <email@example.com>
> >> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian <firstname.lastname@example.org>
> >>> 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
> >> 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
> im 90% certain the icache has been cleared...
> push r0 @ point r0 at where new word starts in code
> ldr r2, =old_dp
> ldr r0, [r2, #BODY] @ point where new word ends in code
> ldr r1, =dp
> ldr r1, [r1, #BODY]
> str r1, [r2, #BODY] @ new end = next start
> movw r7, #2 @ clear icache for selected range
> movt r7, #15
> mov r2, #0
> swi 0
> 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.
> "When something can be read without effort, great effort has gone into
> its writing."
> -- Enrique Jardiel Poncela --