C Kernel

An alternative solution might be temporary stacks. Every entry into “user” code gets a temporary stack that is mapped into a random MB aligned area by an elevated entry veneer handler within CLib.

The pro’s would be task isolation, improved security, reduced chance of stack overrun and it removes the need to preserve the two values. By moving the veneer into CLib, it allows future changes without recompiling every C Module.

Are those two values used solely for the duration of the call? And are they only referenced by user code or does CLib reference them?

I might implement this in ADFFS, I’m already isolating each call with a temporary stack, just not handling the MB alignment. ADFFS goes one step further and drops the CPU to USR, so nothing runs elevated.

One of the offsets is used by your module, one is used by SharedCLibrary. In your module you see

LDR R0, [R10, #-536]

whereas in the SharedCLibrary you see

LDR R0, [R10, #-540]

Every entry into “user” code gets a temporary stack that is mapped into a random MB aligned area by an elevated entry veneer handler within CLib.

Creating a new temporary stack each time the user’s module code is called from somewhere? Like under interrupt, on each service call or through the filing system interfaces?

To be able to register discrete handlers with the various parts of the OS like SW OS_Claim, filing system interfaces etc. you would need to pass in the address of the appropriate veneer-handler in a new CLib as the code to be called (rather than passing that of the CMHG-generated veneer) and, as the associated data, the address of a pair of words containing the user_handler_address and module pw^ (rather than passing the pw^). Then the veneer-handler could retrieve the module instance’s pw^, do the veneer entry and exit wrapping the call to user_handler_address. As well as ensuring consistency this could save quite a few words per C module as currently a separate splodge of veneer code is generated by CMHG/cmunge for each entry point into the module. And a better use of the cache. [Is there a 32-bit-only option in CMHG for modules that are only going to work on RISC OS 5, so could lose the 26-bit code in veneers?]

without recompiling every C app.

We are just talking C modules here though, not apps.

Are those two values used solely for the duration of the call? And are they only referenced by user code or does CLib reference them?

Yes, and Julie’s reply.

Creating a new temporary stack each time the user’s module code is called from somewhere? Like under interrupt, on each service call or through the filing system interfaces?

That’s the idea, although it would allocate from a pool of pre-defined stacks for speed.

The rest of what you’ve describe about how the veneer would work is spot on.

We are just talking C modules here though, not apps.

Typo, now corrected. Is this definitely Module specific, there’s no corresponding App veneer for “elevated entry”? I would imagine any elevated entry into C would need some sort of veneer, Events / CallBack / Channel Handlers / Voices etc as they’d also be performing stack limit checks?

whereas in the SharedCLibrary you see:
LDR R0, [R10, #-540]

And at what points does C perform that LDR? As this is Module specific, I’m assuming it’s within an internal veneer that’s Module specific or a function call that’s only made by Module code?

there’s no corresponding App veneer for “elevated entry”? I would imagine any elevated entry into C would need some sort of veneer, Events / CallBack / Channel Handlers / Voices etc as they’d also be performing stack limit checks?

Haven’t seen a corresponding AppMunge! I guess it’s roll-your-own time. You can compile parts of your application code with stack limit checking turned off, so simple routines wouldn’t need to set sl, but would then be unable to call out to other parts of the application of indeed the SharedCLibrary. I’ve never myself written C code for those handlers, just using assembler in an otherwise C application.

And at what points does C perform that LDR (LDR Rn, [R10, #-540])

Any time the SharedCLibrary needs to access any of its static data – that data could be in application space or RMA depending on the client program; as the SharedCLibrary isn’t linked against its caller, it has to find the address at runtime.

Have a look at the LoadStaticBase and LoadStaticAddress macros in the RISCOS_Lib (contains the SharedCLibrary) asm headers. They assemble different versions of code depending on whether the C library is being built as AnsiLib, which can far more easily obtain the address of its data as it is fully linked – or SharedCLibrary, where it has to go via sl. This only covers the assembler part of the C library; the C part is compiled without/with the -zm1 flag to do the same thing (note not -zM, which client module code is compiled with to do LDR Rn, [R10, #-536]).