Exception/Interrupt API issues in OSAL

[jphickey]

Describe the bug
When running unit tests on the OSAL for the VxWorks, POSIX, and RTEMS environments, it revealed a few minor issues on the implementation side that should be addressed. These are all in the interrupt/fpu/exception API areas for which the CFE FSW does not really rely upon.

1. For POSIX and RTEMS, the FPU exception APIs should all return OS_ERR_NOT_IMPLEMENTED, because these are in fact not implemented. Returning OS_SUCCESS, as some did, implies that the behavior took effect when it did not (this matters to UT). These are:

• OS_FPUExcSetMask_Impl()
• OS_FPUExcGetMask_Impl()
• OS_FPUExcEnable_Impl()
• OS_FPUExcDisable_Impl()

2. RTEMS does not provide a direct equivalent for the OS_IntEnable/OS_IntDisable API like VxWorks has. The implementation had been using rtems_intterupt_enable/disable for this, but the semantics of those calls are different (they are more appropriate for OS_IntLock/OS_IntUnlock). The Enable/Disable implementation should just return OS_ERR_NOT_IMPLEMENTED.

3. The RTEMS OS_IntLock_Impl/OS_IntUnlock_Impl implementation should use the "local" variant of the RTEMS interrupt enable/disable function. This is documented as being identical on single-processor machines but only the local variant is applicable to multi-processor machines.

4. The OS_FPUExcGetMask() API accepts a pointer as an output buffer, so to be consistent with all other API calls that accept a pointer, it should check for NULL and return OS_INVALID_POINTER in that case.

To Reproduce
Execute the OSAL unit tests (including changeset for #313 to enable full testing) and some failures are reported due tot his.

Expected behavior
All unit tests should pass.

System observed on:

• Ubuntu 18.04 LTS 64-bit (native/posix)
• RTEMS 4.11 on i686/pc (QEMU-emulated target)
• VxWorks 6.9 on PPC/MCP750

Reporter Info
Joseph Hickey, Vantage Systems, Inc.