DDT on the Beagle

Trying to work out how DDT 1.89 works etc-
It works on the Iyonix – but give trouble with the Beagle.
At offset &48C0 – it looks as if the instruction should be EQ instead of NE.

ie – should be:-

teq pc,pc
ldreq pc,[r13],#4
^{^
ldmia r13!,{pc}}

Is there any info on the program available?

What sort of assembler was used to produce it -
the ADRL values are different to that produced by !ObjAsm – making to difficult to recreate a exact copy.

Is there anyway of testing to see if pc}^ movs is valid with the SPSR?

Thanks

Well spotted, that looks like a slip up during 32-bitting to me.

DDT is built using Norcroft C and ObjAsm, and ROOL has access to the source code. However, as with many of the other tools, it relies in part on software licensed from ARM, Codemist, Alcatel and others, and as such we have been unable to secure agreement to release the sources. However, ROOL are doing our best to continue maintenance of the toolchain, time permitting. In the last year, we have made several bugfixes to the compiler and linker, and a major upgrade to ObjAsm to fully support ARMv7 is nearing completion.

We’re aware that there are several major issues with DDT, but we haven’t prioritised work on it so far, since the number of developers actively doing development on ARMv7 platforms was limited. However, there have been an increasing number of questions about it lately, suggesting that this has changed, so we’ll probably have to turn our attention to that next.

Is there anyway of testing to see if pc}^ movs is valid with the SPSR?

Well, the ARM architecture says that it’s a valid instruction except if you’re in USR mode. But it’s unlikely to be useful in interrupts-on code because of a policy decision in RISC OS (and probably many other OSes in practice too, I suspect) that interrupt handlers are not required to preserve SPSR_svc.

Every time an interrupt handler calls a SWI, SPSR_svc will be corrupted – or, more precisely, copied from the CPSR at the time, which chances are will be configured to SVC mode with IRQs disabled (but not necessarily). So if that code works more reliably on the Iyonix than the Beagleboard, it only indicates that the Iyonix has fewer interrupts, or that its interrupt handlers call fewer SWIs.

Changing the instruction ldrne pc,[r13],#4 to ldreq pc,[r13],#4 at &48C0 seems to have done the trick for the ‘Beagle’ – Anyone else want to try it?

No luck with the ‘A9’ – I am imformed it locks the machine up.

What is being read at &FF8 in the zero page?

Thanks

What is being read at &FF8 in the zero page?

It looks like it’s a variable called DomainId, which is used to store the active Wimp task handle.