I have a problem report that I'd like to submit.
Description:
In Eclipse, C/C++ editor views gray out parts that it 'knows' are not included in a build. For an STM32 project this does not work flawlessly resulting in some misunderstanding.
Replication:
Create a STM project for a CPU that defaults to hardware floating points using GCC. An example is a STM32Hxx project.
Enable at least one peripheral (RCC in my case, but this step may be optional).
Compile the project and then and open the source file that contains SystemInit()
Observe that according to the Eclipse editor, __FPU_USED == 0 This is unexpected and hopefully wrong!
Also observe that the compiled output contains this conditional block, so the editor is incorrect and the binary is correct. Observe core_cm7.h for additional context/proof. Hint: It relates to __SOFTFP__
Cause:
The indexer operates on a set of pre-processor flags that differs from the ones used during compilation. It is simply not aware of all compiler flags that affect compiler built-in #define-s.
The indexer bases its work on the output from:
${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}"
That translates to:
arm-none-eabi-g++ -E -P -v -dD C:/Users/Me/STM32CubeIDE/workspace_1.0.0/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Note: Odd that ${FLAGS} is empty. This may be a clue.
This in turn outputs the following (and more).
#define __SOFTFP__ 1
#define __VFP_FP__ 1
So what is incorrect is that __SOFTFP__ is defined. It should not be.
Reference: https://wiki.debian.org/ArmEabiPort (look for __SOFTFP__)
On a hunch I changed the indexer command to:
${COMMAND} ${FLAGS} -mfpu=fpv5-d16 -mfloat-abi=hard -E -P -v -dD "${INPUTS}"
That expands to:
xarm-none-eabi-g++ -mfpu=fpv5-d16 -mfloat-abi=hard -E -P -v -dD C:/Users/Me/STM32CubeIDE/workspace_1.0.0/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
This in turn outputs the following (and more).
#define __VFP_FP__ 1
No more __SOFTFP__. Success!
So from what I can deduce there is a problem in the sense that some compiler flags are relevant to the indexer input generation and these are not passed.
The net effect of this is one of minor confusion about what code gets compiled. The effect is limited to code that depends on compiler provided #define-s.
I hope this may be of use to you. Cheers.
