This is a workaround for the GCC not using the strong symbols from
C files to override the weak symbols from ASM files. This GCC bug is only
present when building with the link-time optimizer (LTO) enabled. For
more details please see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967
This can be fixed by changing the order of object files in the linker
command; objects providing the weak symbols and compiled from assembly
must be listed before the objects providing the strong symbols.
To keep things simple, ALL object files from ASM are listed before
other object files.
According to GCC man:
To use the link-time optimizer, -flto and optimization options should be
specified at compile time and during the final link. It is recommended
that you compile all the files participating in the same link with the
same options and also specify those options at link time.
Additionally, move the '-g3' flag out of 'common' flags in the debug
profile. Although the '-g' is correctly ignored by the linker, the
'-glevel' is not and causes a build error "ld: unrecognized option
'-g3'".
- By default, Mbed OS build tools use standard C library for all supported toolchains.
It is possible to use smaller C libraries by overriding the "target.default_lib" option
with "small". This option is only currently supported for the GCC_ARM toolchain.
This override config option is now extended in the build tool for ARM toolchain.
- Add configuration option to specify libraries supported for each toolchain per targets.
- Move __aeabi_assert function from rtos to retarget code so it’s available for bare metal.
- Use 2 memory region model for ARM toolchain scatter file for the following targets:
NUCLEO_F207ZG, STM32F411xE, STM32F429xI, NUCLEO_L073RZ, STM32F303xE
- Add a warning message in the build tools to deprecate uARM toolchain.
- NewLib-Nano C library is not supporting floating-point and printf with %hhd,%hhu,%hhX,%lld,%llu,%llX
format specifier so skipping those green tea test cases.
Planning to update to supporting GCC 9 as found in GNU Tools for Arm
Embedded Processors 9-2019q4-major.
Newer GCC in particular supports ARMv8-M security extensions, and
link-time optimisation - two areas of interest.
Should be no code changes required, but need to change the warning in
the toolchain script.
Change the heuristic for selection of CMSE in the tools python, so that
a non-TrustZone ARMv8 build can happen.
Ideally we would have more direct flagging in the targets, but this
refines the heuristic so the necessary behaviour can be easily
achieved.
* DOMAIN_NS=1 is based purely on the `-NS` suffix on the core name.
* Enabling CMSE in the compiler and outputting a secure import library
is now enabled when the core doesn't have an `-NS` suffix by either
the target label `TFM` being present or the flag `trustzone` being set.
This covers the existing ARMv8-M behaviour - TF-M builds have the TFM
label, as per its documentation; M2351 secure builds have no explicit
flagging, so we ensure that the M2351_NS target has the trustzone flag
set, and the out-of-tree secure target inherits that.
* For ARMC6, core types `Cortex-M4` and `Cortex-M7` did not explicitly
add `--fpu=none`, so it defaulted to assuming FPU present. This would
cause a compilation error if the target's cmsis.h had `__FPU_PRESENT`
defined to 0.
* For GCC, `Cortex-M33FE` did not include `+dsp` in the architecture
selection.
* For ARMC5 and ARMC6, `Cortex-M0+` did not pass `M0plus` to the
non-Clang tools.
The "hook tools" were capable of hooking into many commands run by the build system.
To my knowlage, the only hook is the "post-build-hook". The post build hook could be
easier to reason about if the implementation is specialized for just post-build
hooking.
This commit make it much easier to point out where post build hooks are called by
making the call explicit.
Filip Jagodzinski
Anna Bridge
Martin Kojtal
Rajkumar Kanagaraj
Qinghao Shi
Hugues Kamba
Kevin Bracey
jh228
Jimmy Brisson
Nir Sonnenschein
deepikabhavnani
Michael Schwarcz
Cruz Monrreal
jeromecoutant
Jammu Kekkonen