Re: back into the thread....

[Mark Manning <mark4th at gmail dot com>]

On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian <phi.debian@gmail.com> wrote:
> On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning <mark4th@gmail.com> wrote:
>> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian <phi.debian@gmail.com> 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 --