µVision 5 compiling

This is the message from Keil support:

Dear Sebastian,

sorry for my late response and thanks for checking the project options.
However, the behavior is correct for MDK5 and our latest MDK4 version and was not fully correct
in older versions. Let me explain how Cross Module Optimization works. You will understand why
a re-build is required...

Assuming a "clean" target, the compiler need to build all target files. Now the linker performs
an initial link of all target files and produce a so-called feedback file (.fed). This is
called phase 1 and will not / should not produce any output file as well should ignore all max
sizes provided in the scatter file or Options for Target -> Target dialog since the image
could exceed this limit cause of unused functions. Now uVision read the feedback file and
analyze it to figure out which object files contain unused functions and issue a second build
for this modules. This is called phase 2. Now the linker use the newly build modules and
existing modules to create a new image. Again, the size limits need to be ignored and uVision
need to analyze the newly created feedback file again if there are sill objects with unused
functions. In case there are unused functions uVision will build the modules again, and so on...
In each phase the compiler is invoked, the created feedback file is provided to the compiler.
If the feedback file did NOT contain any reference to a module with unused functions, the
linker is called again but now the feedback options to ignore the size limitations are removed
and the final application image is build.

As you can see, Cross Module Optimization requires some more build steps as expected to get the
fully optimized image. Older MDK versions stop after the first and just build changed files so
the feedback file changes are not taken into account.

Reason for this complex build behavior is: The object file the compiler creates put all
functions into a single ELF section but the linker is only able to remove a section but not a
single function in a section. Therefore the linker mark the function in the feedback file and
the compiler will put this function into its own temporary section which now the linker can
remove. This is how unused function removal works from a top-level view...

I recommend to turn of Cross Module optimization during development if the image will fit to
flash to reduce the build time. If the image is already to large, enabling "One ELF Section per
Function" in Options for Target -> C/C++ can reduce the image size as well but my have some
impact on other optimization methods. For the final production image or validation image Cross
Module optimization can be enabled again.

This is the message from Keil support:

Dear Sebastian,

sorry for my late response and thanks for checking the project options.
However, the behavior is correct for MDK5 and our latest MDK4 version and was not fully correct
in older versions. Let me explain how Cross Module Optimization works. You will understand why
a re-build is required...

Assuming a "clean" target, the compiler need to build all target files. Now the linker performs
an initial link of all target files and produce a so-called feedback file (.fed). This is
called phase 1 and will not / should not produce any output file as well should ignore all max
sizes provided in the scatter file or Options for Target -> Target dialog since the image
could exceed this limit cause of unused functions. Now uVision read the feedback file and
analyze it to figure out which object files contain unused functions and issue a second build
for this modules. This is called phase 2. Now the linker use the newly build modules and
existing modules to create a new image. Again, the size limits need to be ignored and uVision
need to analyze the newly created feedback file again if there are sill objects with unused
functions. In case there are unused functions uVision will build the modules again, and so on...
In each phase the compiler is invoked, the created feedback file is provided to the compiler.
If the feedback file did NOT contain any reference to a module with unused functions, the
linker is called again but now the feedback options to ignore the size limitations are removed
and the final application image is build.

As you can see, Cross Module Optimization requires some more build steps as expected to get the
fully optimized image. Older MDK versions stop after the first and just build changed files so
the feedback file changes are not taken into account.

Reason for this complex build behavior is: The object file the compiler creates put all
functions into a single ELF section but the linker is only able to remove a section but not a
single function in a section. Therefore the linker mark the function in the feedback file and
the compiler will put this function into its own temporary section which now the linker can
remove. This is how unused function removal works from a top-level view...

I recommend to turn of Cross Module optimization during development if the image will fit to
flash to reduce the build time. If the image is already to large, enabling "One ELF Section per
Function" in Options for Target -> C/C++ can reduce the image size as well but my have some
impact on other optimization methods. For the final production image or validation image Cross
Module optimization can be enabled again.