Running multiple versions of CLib

Whilst pondering how to implement APCS-A on ARMv5/v7 and track APCS-R based client’s environments (vector claims, environment handlers etc), I realised it would probably be far simpler to run the 26bit CLib Module version an app wants, within its 26bit environment, rather than translate to APCS-32, as I’m currently doing.

Aside from the obvious issue of conflicting Module names and SWI blocks. What else would be required to for multiple CLib Modules to work in parallel? CLibCount (FE8), RISCOSLibWord (FEC) and CLibWord (FF0) would need virtualzing and I’m guessing IRQsema (108) and DomainID (FF8) possibly need redirecting. Is there anything else I’d need to be aware of?

A quick search through the CLib source suggests that it doesn’t use IRQsema or DomainID. (Tip: most components – or at least those that I had to update for zero page relocation – will use the OSRSI6 symbolic constants, so it’s easy to find where/how OS_ReadSysInfo 6 is being used just by searching the source for ‘OSRSI6’)

I’m not sure how relevant it would be (and might even explain some of the oddities you were seeing with event/signal handling?), but CLib also uses OS_ReadSysInfo 6 to get the SVC & UND stack addresses so that it can work out what’s going on during some aborts – see O_undStack and O_svcStack in kernel.s.k_body.

Of course this is all from looking at the latest version of the CLib sources, so maybe older versions relied on different zero page/fixed locations (and probably had the addresses hardcoded, rather than using OS_ReadSysInfo 6)

Thanks Jeffrey. I gave this a go prior to your post, CLib 1.01 (APCS-A) worked straight away and didn’t appear to be touching Page Zero. All the Magnetic Scrolls games ran first time on ARMv7, so that solved one of my initial aims.

Moving onto the latest 26bit CLib build (from PlingSystem) I had a look at its init sequence. Seeing it was using legal means to get the Page Zero addresses, I redirected them to localised equivalents. Results weren’t so great though, some games worked, most didn’t with odd crashes or lock ups.

I’ll carry on investigating and also try a version of 26bit CLib from the era (circa 1993-1997)

Talking about CLib – is there a way of translating the error – like in RO5.23 – into a call/jump to the CLib?

Address &0225560C is at offset &00015368 in module SharedCLibrary

Does the RO image use a special ‘Stubs’ file for ‘C’ progs which are included in the ROM.

Is it possibe to make a ‘C’ prog that is created stand alone – that can be Rommed?

I believe that the C applications which are in the ROM use the standard stubs.

However C modules are definitely handled differently. ROM builds of C modules use special stubs that don’t contain the jump table. Instead they link directly to the ROM-based CLib. If they had a jump table like standard softloadable modules, it would have to be initialised during the module startup, which obviously wouldn’t work if it’s held in ROM. Linking directly to CLib is also slightly more efficient and saves a bit of ROM space.

There’s also the problem that the C compiler can’t (or won’t) generate read-only relocatable code. ROM builds of C modules are statically linked to run at their location within ROM, while softload versions rely on the auto-generated __RelocCode function to go through the binary and fix up any constant pointers to be correct for the current location of the module.

Could you please ref a RO module that is in ‘C’?

(There seems to be another option of – Relocatable Module Linker – by Adrian Lees – But not sure if it is available to all)

Note restubbing soft loadable RModules (26bit stubs to 32bit)

Ref the auto-generated __RelocCode function.

Without resorting to adding by hand – what you call ‘constant pointers’ to the end of module – is there anyway to tell the ‘Linker’ which (words/pointers) need to be added?
ie like:-
RelocCode &number

So the main file (with the 26stubs code removed) can be linked to the 32bit stubs.

Hope that makes sense!