5.30 Stable

SharedCLibrary 6.23 15 May 2024 fixes the SWP collision.

I had read the change, and could see no bearing on the SWP problem, and indeed can see no relevance having read it again.

It’s a bit subtle but the SWP avoidance is hiding at line 1119

The key bit (and Ben beat me to it so saved me having to get the JTAG debugger out) is that the O__swp_available flag isn’t set up when the CLib is RMLoaded, because the flag is in the client’s workspace, so it’s not valid until the client’s done something as an application.

Why does that change do anything?

Calling free(NULL); is defined to do nothing, and in the ROM case what it was doing was

• Pointer doesn’t match as being in the RMA [correct]
• Go to _primitive_dealloc [correct]
• ACQUIREMUTEX
• Not match as being in the heap [correct]
• Match on block == NULL [correct]
• RELEASEANDRETURN
• Overall effect…does nothing [correct]

In the softloaded CLib case that ACQUIREMUTEX was tripping up because the O__swp_available is unset, taking the non-ARMv8 safe path to SWP.

In the new version the block == NULL test is done right at the beginning, thus skipping the mutex code entirely.

Thanks for the explanation, Rob – that is all way above my pay grade!
And thanks to Ben for fixing it.