C Kernel
Jon Abbott (1421) 2640 posts |
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. |
Julie Stamp (8365) 467 posts |
One of the offsets is used by your module, one is used by SharedCLibrary. In your module you see
whereas in the SharedCLibrary you see
|
Stuart Swales (8827) 1323 posts |
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?]
We are just talking C modules here though, not apps.
Yes, and Julie’s reply. |
Jon Abbott (1421) 2640 posts |
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.
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: 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? |
Stuart Swales (8827) 1323 posts |
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
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 |