Strict-type errors/exception when creating TimeBase callback on RTEMS during cFS init

[pepepr08]

Describe the bug
A memory alignment exception occurs when running with RTEMS on GR740 board when compiling with OMIT_DEPRECATED = true and MISSION_RESOURCEID_MODE = "STRICT"

The exception occurs during cFS init, when starting the TimeBase callback task/thread:
https://github.com/nasa/osal/blob/main/src/os/rtems/src/os-impl-timebase.c#L392-L395

The callback thread OS_TimeBase_CallbackThread function argument is of type osal_id_t.
https://github.com/nasa/osal/blob/main/src/os/shared/src/osapi-timebase.c#L381

RTEMS expects the callback function argument to be of type rtems_task_argument. The conversion from one type to another when starting the task causes the exception.

To Reproduce
Build for rtems5-gr740 with OMIT_DEPRECATED = true and MISSION_RESOURCEID_MODE = "STRICT"
Run cFS on gr740 board

Expected behavior
Successful cFS init.

System observed on:

• Hardware: GR740
• OS: RTEMS 5
• Versions: Draco

Reporter Info
Jose F Martinez Pedraza / GSFC 582

[pepepr08]

Possible solution is to create a helper function like this (with better name and comments):

static void OS_TimeBase_CallbackThread_rtems(rtems_task_argument arg)
{
  osal_id_t id;
  id = OS_ObjectIdFromInteger(arg);
  OS_TimeBase_CallbackThread(id);
}

What do you think @jphickey ?

[skliper]

@acudmore - any opinions on this one? Should probably get it resolved in Draco.

[jphickey]

Just saw this (sorry I missed the mention from Apr 6) ... but yeah there should just be a wrapper function to deal with the different data type. For example the POSIX implementation already has it, see OS_TimeBasePthreadEntry here:

osal/src/os/posix/src/os-impl-timebase.c

Lines 314 to 321 in 1de47bb

	static void *OS_TimeBasePthreadEntry(void *arg)
	{
	OS_VoidPtrValueWrapper_t local_arg;
	local_arg.opaque_arg = arg;
	OS_TimeBase_CallbackThread(local_arg.id);
	return NULL;
	}

I think rtems_task_argument was an int in 4.11 so a wrapper wasn't strictly needed but its definitely preferable (and more type safe, future proof) to use the entry point wrapper like POSIX has.