C RM Modules 26-32 bit

C Modules 32bit

Ref modules written in ‘C’ for 26bit and converted to 26/32 bit.

Having a go at some 26bit modules that time has left behind for various reasons :-(

Any tips – would be handy.

The way I did the first one was build a 26 bit and 32 bit version of a C module that I had written, feed them in to ARMalyser and what had changed. This allowed me to make a generic replacement 32 bit C stubs for a module, which I could use to replace the 26 bit version in modules I was porting. The stubs consists of the C.String, InitProc, Main_entry_point, Module_entry_point, kernel_init, kernel vector table, clib vector table, Shared_Clib_Stub_Chunk, SharedCLib_Language_Block, and the Read/WriteArea (not strictly part of C Stubs). Note that locations in the read/write area maybe be referenced in labels in the code, and those labels need adding back in to the new stub at the correct offsets.

Probably the best way of seeing how this works is for me to send you a before and after module, which you can look at in !SideDiff to see what has been changed.

Have used your handy ‘C’ Mod Templates to 32bit a few ‘C’ modules.

A few got-urs – like code between the stubs.

A try out that worked with FF8 Absolute code but would return SVC to USER mode in modules :-(

I was wondering if something for Mod testing would work.

Like

In the start chain of SWIs

Str r13 , space
Msr cpsr_c,#0 ; 26bit
Ldr r13,space

To force User in a module for testing and continue with using the SVC stack.

Noooo! For a start, you will have SWIs being called from IRQs – those use the real SVC stack. That will cause your stack contents to be overwritten in the background (as well as any self-inflicted injuries caused by that module code itself calling SWIs). And then you’ve got to get back to SVC mode to return to the OS SWI handler return code. Vom.

If these are SWI handlers which don’t really need to be in SVC mode, e.g. transforming format a to format b, I’d be tempted to construct a BASIC test harness that loaded the original RM into a DIM-ed block, performed your patches, CALL-ing an assembler veneer that set up registers appropriately and then directly called the SWI handler code in that RM to be tested.

Is there a explanation on how ‘C’ module programs works – who thought up the relocation/patching of some of code when the file was loaded in the RMA?

It’s not that different to how ‘C’ absolute programs work, i.e. bloody complicated. There is information in the DDE manuals on SharedCLib initialisation, which can read alongside a disassembly of some code, and see how it lines up.