Building the RTD with GCC Space Optimization

[greenwichmeanie]

We're using the NXP GCC 11.4 compiler and have created our own CMake build. The compilation flags were lifted from the Design Studio project. It builds and runs but if we remove the `-Os` flag we see hard faults. I wouldn't expect the removal of an optimization to change the behavior of the code (let along cause it to crash). I'd like to understand why this is. We have a functional safety application and it'll be important to understand and document this.

Thanks.

[jleveque]

I encountered this exact issue after creating my own CMake project using "-O0" optimization for my Debug build, and wasted time figuring out what was wrong (thank you, @greenwichmeanie for posting this topic, which saved me some time in confirming that the issue lies in the optimization level!). It appears that the issue may be related to the implementation of the "#pragma GCC section" patches NXP applies to GCC and how they behave with different optimization levels.

@VaneB: Above, you claim,

Additionally, each RTD release note specifies the optimization level used during development and testing; most RTD releases have been validated with -Os/-Osize.

While I understand you can't feasibly test and validate every possible combination of compilation flags, I believe it is reasonable to expect to be able to build and debug with no optimization (-O0). Being forced to debug a binary compiled with -Os is challenging, as the compiler inlines many functions and reorders code. I would appreciate it if you could pass on a request to support compiling with the "-O0" optimization level.

[Henrik-Wires]

I second this. Building with -O0 is a default goto when debugging code issues to avoid getting confused by compiler artefacts, but not on S32K3.

[greenwichmeanie]

Thanks VaneB. Point taken. We'll take a look at the release notes but I have no reason not to believe you.

For what it's worth we tracked this down. If a couple of specific optimization flags are removed (from the collection included when using -Os) then the variable below is not initialized by the C runtime initialization. It remains set to null by the time `main()` is reached (which is obviously a problem). Happens with GCC 10.2 and 11.4. If we halt the debugger and punch that address in then things are fine.

That assignment was happening before the definition of Clock_Ip_CodeInRamSetFlashWaitStates. If we move the assignment after all is well.

#ifdef CLOCK_IP_HAS_FLASH_WAIT_STATES
static SetFlashWaitStatesCallbackType Clock_Ip_SetFlashWaitStatesCallback = &Clock_Ip_CodeInRamSetFlashWaitStates;   /* Set Flash Wait States callback */
#endif

[VaneB]

Hi @greenwichmeanie 

Thank you for sharing your findings.

[VaneB]

Hi @greenwichmeanie 

Please note that none of the currently available RTD versions for S32K devices (S32K1 and S32K3) support NXP GCC 11.4. Additionally, each RTD release note specifies the optimization level used during development and testing; most RTD releases have been validated with -Os/-Osize.

Therefore, we cannot guarantee the functionality of the drivers when using different optimization levels or toolchains than those originally tested. Furthermore, any modifications to the RTD fall outside the scope of our support.

BR, VaneB