Avoid alignment warnings on some CPUs

[jphickey]

Describe the contribution

• Fix Alignment warnings when casting char* pointers #437

Partially address #313 (overlapping issue)

On CPUs with strict alignment requirements, some CFE code that uses a char-type pointer (e.g. uint8*) to compute memory addresses triggers an alignment warning when it gets cast back to the actual data type.

In the mempool implementation, the pointer should be sufficiently aligned already, because the address computation already takes CPU alignment requirements into account when calculating the addresses/offsets.

• For the CFE_SB pool buffers, using the cpuaddr type, which is integer in nature, avoids the warning.
• For the CFE_TBL internal table pointer, use a void* internally to store the buffer pointer, rather than a uint8_t*. This changes the casting needs elsewhere.

Testing performed
Build CFE with ENABLE_UNIT_TESTS=TRUE
Confirm all unit tests passing
Perform sanity test on CFE (normal startup, send commands from console)
Build for MIPS64 and ensure that (some) alignment warnings are fixed

Expected behavior changes
No change to behavior. Fixes build warnings only.

System(s) tested on:
Ubuntu 18.04 LTS 64-bit

Additional context
There are still some remaining alignment cast warnings regarding the message types, where a local message buffer is cast to a CFE_SB_Msg_t* which has a higher alignment requirement. This is a little harder to fix as it requires changing the local buffer definition.

Contributor Info
Joseph Hickey, Vantage Systems, Inc.

Community contributors
You must attach a signed CLA (required for acceptance) or reference one already submitted

[jphickey]

Update: changed the description to reflect that this will fix the char* casts cited in #437 but the older issue #313 also mentions issues related to the message types (CFE_SB_Msg_t* casts) that this does not fully address.

There will need to be an additional pull request to fix those ones.

[CDKnightNASA]

Looks fine to me, does this mean however that the pointer may not be aligned? I don't know if there are any CPU's that cannot interact with unaligned data but it will affect performance on many platforms. Should we add code to align?

[jphickey]

does this mean however that the pointer may not be aligned? I don't know if there are any CPU's that cannot interact with unaligned data but it will affect performance on many platforms. Should we add code to align?

SPARC and MIPS processors (at least) will throw an exception when attempting to access a data structure that is not properly aligned. I believe ARM and x86 will auto-correct but there is a performance penalty to pay. Not sure about PowerPC.

For the items specifically in this pull request (the pool address calculation) the buffer descriptor is already a union including large types, such that sizeof(BD_t) will be a multiple of the system alignment required for the large. In turn all pool buffers are also already allocated to be a multiple of this size.

So all the pointers are already aligned sufficiently, the problem is merely that it was using uint8* intermediate pointer to perform the address calculations, and then casting a uint8* back to the intended type. This final step is what triggered a warning, just because the final type has a stricter alignment requirement than uint8* does.

By doing the intermediate address calculation as an integer (cpuaddr) the result is exactly the same but gcc doesn't warn about it.

[skliper]

CCB 20190108 - Reviewed and approved for integration candidate