Optimization without "-ffunction-sections" and "-fdata-sections"

[ahmedhrabi]

Hi all, 

I'am using the K64 on McuXpresso and 2.8 SDK (fsl drivers) and Arm math library of CMSIS in my project.

WIthout compilation optimization (-O0), the project works like a charm. 

But with the compilation optimisation (-O1, -O2, -O3), the application have a wired behaviours, but adding the flags  "-ffunction-sections" and "-fdata-sections" in compilation, solved the problem. 

(All volatile variables are declared correctly)

Have any one some explications. 

Best regards. 

[ahmedhrabi · Accepted solution]

@ErichStyger 

Thanks for your reply. But i have to notice that the flag --gc-sections is activated on the project, that removes the unused data and code from the final executable, and this delete operation is performed by the linker. 

And to use this option ("--gc-sections") it's mandatory to use the "ffunctions-sections" and "-fdata-sections" options as mentioned in this GCC gnu link: https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gnat_ugn_unw/Compilation-options.html

best regards, 

Ahmed.  

[bobpaddock]

Using ADA?

Regardless:

"This will perform a garbage collection of code and data never referenced."

"never referenced" does not always mean 'unused'.
Such as my ISR comment to Erich above.

I know you stated that all the volatiles were correct.

I've yet to find a case were going from -O0 to anything higher was not some how related to volatile or something 'unreferenced' was not the actual issues with code that stops working with optimization turned on.  -O3 is not always recommended either, as it can be overly aggressive depending on the architecture.

Also are using the 'Small' model?  -Os
I have also seen issues on ARM with that, while on AVRs it always helped.

[ahmedhrabi]

Hi @bobpaddock, 

No i'am not using ADA,

i'am using the -O3 optimization and not -Os.  

I know that -O3 is so aggressive and i use it to validate the project and to make sure that the code do not contain cashed problems or timing dependencies bugs. 

Regards. 

[ErichStyger]

The interrupts should not be removed.

But they need to be treated in a special way, e.g. in the linker file:

KEEP(*(.isr_vector))

I did had some wrong removal with -LTO especially in the FreeRTOS port (I have modified FreeRTOS so it links fine with -LTO. Other than that LTO has helped me to find some issues in code too: https://mcuoneclipse.com/2018/05/31/gnu-link-time-optimization-finds-non-matching-declarations/

My experience with aggressive optimizations in gcc is that they are working well: whenever I have found issues they were not because of the optimization but because the optimized code uncovered a bug (e.g. some stuff not properly initialized): without optimization things were just running fine by pure luck, and the optimization exposed the problem.

BTW: volatile does not help for any race condition or reentrancy problems: it only helps and is appropriate if a hardware register changes its value after a write to it, or if a read of the register has a side effect on that register. Nothing else. If volatile is used for anything else than hardware, this is usually  sign of a programmers problem (there are a few exceptions, of course).

Erich

[bobpaddock]

"KEEP(*(.isr_vector))

I did had some wrong removal with -LTO especially in the FreeRTOS port (I have modified FreeRTOS so it links fine with -LTO. Other than that LTO has helped me to find some issues in code too: https://mcuoneclipse.com/2018/05/31/gnu-link-time-optimization-finds-non-matching-declarations/"

Keeping the vector table is different, unless all of the ISRs are put in that section too.

We actually had this same 'used' discussion in the comments of the link you posted there.

LDFLAGS += -flto-report

can add an agenizing level of details as to what lto did.

Also:

# LTO is broken in until ARM version GCC 8.3.
# -gX must be turned off when LTO is turned on.

# Note that the same optimization flags (-flto -Os) shall be passed
# both at compile time and at link time.

"volatile does not help for any race condition or reentrancy problems: "

Yes, its only use is to inform the compiler that the marked location can change its value outside of the compilers awareness.  Any other implied usage by marking something as such is wrong.

[ErichStyger]

Hi @ahmedhrabi ,

these options place functions and variables into their own sections so the linker can remove them if they are not used. The impact is that everything unused gets removed.

So technically it should not matter if you have it or not, except your application gets smaller. Now the changed memory layout and allocation could have an impact with 'wild running code' or 'dangling pointers'. So you would need to find out with the debugger what is going wrong exactly in your code. These options I think have not caused it, they just might have uncovered or covered an issue in your code.

Erich

[bobpaddock]

It is a good idea to mark Interrupt functions as USED.

I have seen them removed when trying these esoteric options such as 'sections' and Link Time Optimization (LTO).

I'm curious what your experience with LTO might be?
I've never had succus with it it here or on AVRs.
Always end up with broken code.

In general I use Lint to make sure there is no dead code or data in the first place.

Example:

void USB_IRQHandler( void ) __attribute__( ( interrupt( "IRQ" ), no_instrument_function, used ) );
void USB_IRQHandler( void )
{

}

There is a discussion of how GCC's options to make things smaller can make things larger and/or break things here:

https://stackoverflow.com/questions/4274804/query-on-ffunction-section-fdata-sections-options-of-gcc