Error handling in SharedCLibrary in ROM

Before I raise a bug issue, I wonder if someone else could have a gander and see if I’m being an idiot.

https://croftnuisk.co.uk/coltsoft-downloads/other/error-bug.zip

Tiny C test program which installs a signal handler and raises an error for that to catch (yes, I tried three ways). When it’s compiled and linked with Stubs (DDE 31a) and uses the SharedCLibrary in ROM¹, the signal handler is not called as the SharedCLibrary’s own error handler seems to trap.

But link the object file with AnsiLib, and the executable behaves as expected. And if SharedCLibrary is RMLoad’ed, the Stubs-linked executable works fine too.

1. Pi 4, RO 5.29 (13 Dec 2022)

Oh, it’s been that way for 20 years! [Edit: potentially – see Jeffrey’s reply below]

ADD     r14, r0, #O_registerDump

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/blame/master/kernel/s/k_body#L1614

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/commit/350370aa3fee849c6f821bc69235d854a0ed2f26

From RPCEmu

*FX0
RISC OS 4.39 (28 Apr 2004) [Kernel 6.80]
*help SharedCLibrary
==> Help on keyword SharedCLibrary
Module is: C Library       6.15 (21 Sep 2022)
*err
Aha! An Error: &00000001/1 Ooh Err
*
*fx0
RISC OS 5.29 (15 Dec 2022)
*help sharedclibrary
==> Help on keyword SharedCLibrary
Module is: C Library       6.15 (21 Sep 2022)
*err
Aha! An Error: &00000001/1 Ooh Err
*

I compiled it with cc 5.39 (DDE31) and ran it fine under RO 5.29 (04 Dec 2022).

Aha! An Error: &00000001/1 Ooh Err

Thanks

From RPCEmu

I surmise that the RISC OS 5 IOMD target has SASTMhatbroken set, as will the soft-load SCLs.

And RISC OS 4.xx was forked off before the offending implementation.

I can’t see a good reason why the error handler in the SCL immediately goes into SVC mode to dump the USR mode registers as it is in USR mode. OK, ‘nowadays’ it needs to load the error number to decide whether to overwrite the current register dump, so it could just lob R14 into one of the unused words of R0-addressed static data, decide whether it is going to dump registers (R0-R13,no-hat) and if so stick the stashed R14 in the register dump. No STM^ / SA bugs to worry about.

The good news is, it looks like the buggy code path would have only been enabled a few months ago, when the SASTMhatbroken switch was rationalised to only be TRUE when targeting older CPUs (previously it was on for all builds).

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/commit/3b7d39bdeb781fba7b1b47780f7d754c374152a0#4daf1ceff9933c39476a5a46ed7414a066d418b2_43_35

The good news is, it looks like the buggy code path would have only been enabled a few months ago…

Aha!

Small question, I just did the tests, for the SharedCLibrary it only works if I Rmload this library and unplug the one in ROM.
Both libraries have exactly the same version and the same date, they are different after unsqueeze. The library in rom would not be correct?
I use an ARMX6 and I installed the latest version of the OS.5.29 21/12/2022

The example of error handling is interesting, on my side I use OSLibSupport.

Thanks.

Small question, I just did the tests, for the SharedCLibrary it only works if I Rmload this library and unplug the one in ROM. Both libraries have exactly the same version and the same date, they are different after unsqueeze. The library in rom would not be correct?

The SharedCLibrary that’s in the ROM is optimised for your system (and statically linked to its build location as far as I can tell, so RMFaster is no help to try to patch it). It’s not useful to try to save out the SharedCLibrary (or many other ROM modules these days).

The example of error handling is interesting, on my side I use OSLibSupport.

I think OSLibSupport is more for displaying error messages from your application; this particular issue is dealing with the problem of errors returned by the OS to the application via the Error interface. e.g. exceptions raised from the floating point support code will stick their head up and surprise you there!

the buggy code path would have only been enabled a few months ago

Somewhere there’s a Gerph hitting his head on the table and mumbling something about tests…

they are different after unsqueeze.

As Stuart says, they’re not identical. While the code is the same, if the target is known then some things can be optimised, different build flags, etc.
I can imagine the softload might still have to deal with a 26 bit world, something that’s just not applicable to a modern machine.

Plus, since it’s in “ROM”, it can hard link to bits of itself because nothing is expected to move.

The latter is something that caught people out back in the day when magazine cover discs used to include frequent CLib updates.
It was “safe” to softload a new CLib on an active system that had some software using the ROM library, because all of the links are valid and won’t change. Same with things like Edit and FilerAction.
But loading a new softload on a machine with a softloaded library? Expect it to crash nastily, as all the links will now be invalid.

I’m of the opinion that a softloaded C Library should refuse to die (just install the new one and reboot), but for whatever reason this was never done.

Anyway, the tl;dr is that a ROM build won’t match a softload, even if it claims to be the same.

dealing with the problem of errors returned by the OS to the application via the Error interface. e.g. exceptions raised from the floating point support code will stick their head up and surprise you there!

Yeah, the environment is a bit simplistic at times. When I discovered the borked versions of AcornHTTP, it was because my app was crashing.
Well, actually it wasn’t. But my app was the first error handler that the system encountered in passing up the execution.

Perhaps there ought to be some sort of layer in between so the OS can correctly report what raised an important error (especially if it’s in module code) rather than slaughtering whatever the foreground task happens to be…?

Perhaps there ought to be some sort of layer in between so the OS can correctly report what raised an important error (especially if it’s in module code) rather than slaughtering whatever the foreground task happens to be…?

Perhaps nobody got the memo about not generating errors in non-application module code. I’d go as far as to say the OS ought to detect such things and just bloody well Unplug the miscreant.

Merge request created.

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/merge_requests/26

Merge request created.

Ah, thanks – was just doing something else and about to get round to that! But best done by the Maestro. :-)

And the fix is in today’s ROM build – thanks!

Perhaps nobody got the memo about not generating errors in non-application module code. I’d go as far as to say the OS ought to detect such things and just bloody well Unplug the miscreant.

I don’t know exactly what Gerph implemented in the Select versions of RISC OS to handle background errors but it was nice to see an error box reporting the error and disabling(?) the faulty module/callback/interrupt handler instead of killing of the current foreground application. I know that it involved using some extra bytes near the stack limit to store some context on entry of handlers be able to recover safely to the current foreground task, because AMPlayer’s seeking seemed to corrupt that data.

I don’t know exactly what Gerph implemented in the Select versions of RISC OS to handle background errors but it was nice to see an error box reporting the error and disabling(?) the faulty module/callback/interrupt handler instead of killing of the current foreground application.

Much (all?) of the error logging and reporting was run through a version of syslog that went somewhat beyond the v0.20 available to non-Select versions of the OS

I don’t know exactly what Gerph implemented in the Select versions of RISC OS to handle background errors but it was nice to see an error box reporting the error and disabling(?) the faulty module/callback/interrupt handler instead of killing of the current foreground application. I know that it involved using some extra bytes near the stack limit to store some context on entry of handlers be able to recover safely to the current foreground task, because AMPlayer’s seeking seemed to corrupt that data.

https://www.riscos.com/support/developers/riscos6/diagnostics/backgrounderror.html

https://www.riscos.com/support/developers/riscos6/diagnostics/bts.html