The GCC flag to specify the floating-point hardware (`mfpu`) does not accept
the value `none`. The default value is `auto` which causes the compiler to
select the floating-point and Advanced SIMD instructions based on the
settings of -mcpu and -march. The extension option `+nofp` has been added
to disable floating point instructions.
Move the fpu settings across all cores so they are aligned.
Some cores did not have fpu set for ARMClang. I matched here both toolchains to set up
the fpu the same (Only exception is soft vs hard - that is separate issue I would not like to touch
in this series).
Set DOMAIN_NS=1 only for _NS cores. We had it otherway around.
I verified one non NS target that was failing to build, plus also checked the old tools
that had this definitions:
```
91: "Cortex-M23-NS": ["__CORTEX_M23", "ARM_MATH_ARMV8MBL", "DOMAIN_NS=1",
92 "__CMSIS_RTOS", "__MBED_CMSIS_RTOS_CM"],
93 "Cortex-M23": ["__CORTEX_M23", "ARM_MATH_ARMV8MBL", "__CMSIS_RTOS",
94 "__MBED_CMSIS_RTOS_CM"],
```
Some armasm flags are passed to the ASM whilst we actually use armclang to invoke it. This causes build failures as armclang is not compatible with armasm flags.
This commit passes the same flags to all tools in the chain.
The new function (mbed_set_cpu_core_definitions()) should always be
called as it has defintions needed by Mbed OS to work with that
particular MCU core.
mbed_set_cpu_core_options() should only be called if a third-party
toolchain file has not been used as it has compile options that can
cause conflicts.
mbed-os consists of mbed-core and mbed-rtos
mbed-baremetal consists of mbed-core
The main change is for mbed-core. Changing from object library to be interface. This way it allows us to do the above to have 2 main targets for users to use.
This should be backward compatible change as mbed-os target we used contains the same files/options as previously set.