Degugging gpSP

The porting process of gpSP has been going forward quite well until this came up. The code behavior in debug session seems to be very strange.
The following code should branch into the address located in register r0. The address 0x9cc00080 is marked as code in Symbian OS, and IMB_Range() has been called in prior to execution.

bx r0  @r0 value is 0x9cc00080

However, when debugging it seems that the pc is going into address 0x9b14a4a8.
Here is some debug data from carbide:

1. call stack
2. registers during this time
3. memory starting from 0x9cc00078. It seem to be mapped to code
4. call stack after branch
5. registers after branch

I really can’t tell why this is behaving in such odd way. Hopefully some ARM guru is reading this and knows the cause for this problem.
I’ll make a post, when i’ll get this one solved…

Update

I copyed the memory from the memory area that should be executed. I’m hoping to find some guys from gp32x to see, if they have similar memory in execute_arm_translate function before the first branch. If the memory seems different, then that would explain a lot.. here is the memory in a text. file memory.txt
I originally used N96 with ARM9. I wanted to test this code also with N95 and a newer ARM11 processor. The debugger worked a lot better with N95. Here is the _real_ crash.

generated memory in N95

This one shows that it jumps correctly into the generated code area and it even works. However branch avay from the generated code is the problem. After this it will be in the unknown opcode. This is the point where the N96 actually crashes, the debugger just can’t handle the generated code are correctly.
The lesson is to use N95 for debugging instead of crappy N96. However N96 was a great help in AntSnes porting, it helped me to point out the code that was working with ARM9 and failed with ARM11 and N95.
The code is being executed inside the rom_translation_cache and it branches into the ram_translation_cache memory area. However that memory area is still null. Well, it gets easier now, since I now where to look at.. Hopefully I will be running the emulator on my next post 😉

Update 2:

The problem with the real crash was that the branch address weren’t inside the 32Mb limit of ARM processor. The solution was to implement a memory trampoline between the static and dynamic code blocks.