RE: back into the thread....

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.

Arnab

> -----Original Message-----
> From: Mark Manning [mailto:[email protected]]
> Sent: Wednesday, November 13, 2013 4:59 AM
> To: Phi Debian
> Cc: Sterling Augustine; [email protected]
> Subject: Re: back into the thread....
> 
> On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian <[email protected]>
> wrote:
> > On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning <[email protected]>
> wrote:
> >> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian <[email protected]>
> 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
> 
> 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 --