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 sct file path generated in the online compiler
is incorrect. Fix that by changing the correct_scatter_shebang
API to accept a FileRef object instead and use the path.
This change should go with change in online compiler that removes
the override for correct_scatter_shebang.
There are two new functions: get_valid_toolchain_names and
find_valid_toolchain. These functions are used to figure out if a
fallback is possible and necessary. find_valid_toolchain is expected to
be used by the front-end scripts.
get_toolchain_name was updated with some different logic and comments.
On Windows 7 using --preproc option in ARMC6 assembler doesn't work
when -MD option is also specified. Compiler creates incorrect filename for
dependency file and compilation files.
To workaround this issue, this change returns to using a temporary file and
separately calling preprocessor and assembler (as in a case of ARMC5).
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.
Below are the options read from the toolchains/arm
armclang --target=arm-arm-none-eabi -mcpu=list
The following arguments to option 'mcpu' can be selected:
-mcpu=cortex-m0
-mcpu=cortex-m0plus
-mcpu=cortex-m1
-mcpu=cortex-m3
-mcpu=cortex-m4
-mcpu=cortex-m7
-mcpu=cortex-m23
-mcpu=cortex-m33
...
armlink --cpu=list
The following arguments to option 'cpu' can be selected:
--cpu=Cortex-M0
--cpu=Cortex-M0plus
--cpu=Cortex-M1
--cpu=Cortex-M1.os_extension
--cpu=Cortex-M1.no_os_extension
--cpu=Cortex-M4
--cpu=Cortex-M4.no_fp
--cpu=Cortex-M7
--cpu=Cortex-M7.fp.sp
--cpu=Cortex-M7.no_fp
--cpu=Cortex-M23
--cpu=Cortex-M33
--cpu=Cortex-M33.no_fp
--cpu=Cortex-M33.no_dsp
--cpu=Cortex-M33.no_dsp.no_fp
...
armclang --target=arm-arm-none-eabi -mfpu=list
The following arguments to option 'mfpu' can be selected:
-mfpu=fpv4-sp-d16
-mfpu=fpv5-sp-d16
-mfpu=fpv5-d16
...
For binary compatibility with ARMC5, use the hard ABI variant whenever
we have FP hardware - this is ARMC5's default behaviour, which we do not
override.
Cortex-M4F was already using hard; this brings M7F and M33F into line.
The 'archive' method of the toolchain class 'ARM' expects that self.ar
is a string, but the constructor of the class 'ARMC6' initializes it
with a list. This patch fixes the issue.
### Description
The prior fix made the assumption that you wanted to compute all of the
parents for a give header file going all the way up the path. This is
not true: you probably want to stop when the project stops. We already
keep track of a virtual name within the project, so instead, we compute
parents of the name, and generate the actual location of these files in
your FS as the path. This makes the solution robust offline and online
(I tested it with my local copy of os.mbed.com)
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change