### Description
I noticed that there was quite a bit missing from the mbed2 release of
the microbit today. That's because the microbit uses ARM by default and
the GCC_ARM small library. The release script was trying to release for
ARM using scan rules for uARM. Turns out we're stuck with 2 configuration
parameters for the same thing: `default_lib` for GCC and `default_toolchain`
for ARM. Dang
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change
-mcpu option if set for v8M CPU;s it will add DSP feature as default
which is optional. Hence setting just the architecture for Cortex-M23
and Cortex-M33
1. Add linking time preprocessor macro __DOMAIN_NS for non-secure build
2. For output .hex format, combine multiple .hex files (for multiple load regions) into one
This can help for Greentea test.
3. Fix 'None' build_dir with cmse_lib.o on Greentea test
Cortex v8 architecture based devices support secure/non-secure builds.
Secure build should generate the object file/library from elf during link
process which is used by non-secure binary during linking.
--out-implib=file specifies output library in which symbols are exported
--cmse-implib requests libraries mentioned above are secure gateway
libraries
Creation of secure library is done as part of linking process in GCC/ARMC6/IAR
Non-Secure project should add this secure object file as part of the
linking process.
Secure library is named as cmse_lib.o.
ARMC6 support required ARM compiler support as mandatory requirement which
should not be the case. Cortex-M23/M33 devices are not suuported by ARM compiler5
Adding ARMC6 without ARM in target.json should work now.
While ARMC6 does use the same linker (armlink) as ARM Compiler 5, it
is not compatible.
The reason for this incompatibility are twofold:
* armlink may invoke the C preprocessor by adding a shebang
(`#!`) to the top of their input files.
* ARMC6 and ARMC5 differ in how you invoke the preprocessor:
* ARMC5: `#! armcc -E`
* ARMC6: `#! armclang -E`
This forces the tools to rewrite the shebang if it's wrong.
This does not yet handle dependencies properly
targets.json contained a key for some targets, `OUTPUT_EXT`, which I
moved to `Target`, the root of all targets. Following on that, the tools
now use this extension provided by `OUTPUT_EXT` to determine the file
type of the output executable.
This is a bug fix for the following bug (Github issue #437):
If two builds were run specifying a non-default build folder, the second
build would fail to link with duplicate symbols and may not fit on the
device. The root of this problem is that these non-default build folders
are not ignored by scan-resources, and therefore included in the build.
We fix this bug by ignoring the build directory passed into the tools.
On the ARM toolchain linker flags specified in the build profile do
not get passed to armlink. This patch adds these flags to the
arguments sent to armlink.
Before the toolchains would ignore error messages that contained the
string "Fatal error". This would lead to a silent failure unless the
compile command was ran with verbose options. This is now fixed.
This functionality was already present in the ARM toolchain script, but
this commit adds this across all toolchain scripts. Solves an issue that
cropped up where a build error wasn't being printed unless the verbose
flag was used. This should now print any existing error messages that have
been printed when the compiler output is being parsed.
Fixes#2360.
New error:
[Error] Toolchain path does not exist for IAR.
Current value: /default/path/that/doesnt/exist
(System exit before any build system calls)
* added/improved global chroot support
* added RESPONSE_FILES flag to support optional response files (on linux the cmd param length is 2 megabytes). Default True
* added unified handling for archive and link response file (similar to includes)
* added COMPILE_C_AS_CPP flag to support compiling of c files as cpp. Default False
* added mbedToolchain.init() for post __init__ hooks
* added caching to mbedToolchain.need_update() to reduce IO hits
* added support to identify compiler warning/error column (supports ARMCC, GCC and IAR). Errors/warnings now report file@line,col
* added global TOOLCHAIN_PATHS which allows overriding/changing of the toolchain paths. Also simplified ARM-related paths
* added target.json to mbed library release (by @0xc0170)* migrated compile_worker() to utils.py for lightweight thread initialization
* improved run_cmd() performance by removing unnecessary check about the command being executed (should be checked once in the relevant toolchain instead)
* removed remnants of Goanna support (should be reimplemented as hooks to compile/link/archive instead)
* fixes for Python 2.7 compatibility (by @0xc0170)
* fixes for Exporters (by @0xc0170)
- removing redundancy as discussed in PR #2087:
- in target.json the core option can have only this values : "Cortex-M0", "Cortex-M0+", "Cortex-M1", "Cortex-M3", "Cortex-M4", "Cortex-M7", "Cortex-A9" - Cortex-M4F and Cortex-M7F removed
- in target.json an additional fpu option with values: "single" and "double" can be used
- build and export scripts are changed to handle this
- tested (compiling, running on hardware) with nucleo_f767 (cortex-m7 with double precision fpu), nucleo_f746 (cortex-m7 with single precision fpu), nucleo_f446 and nucleo_l467 (cortex-m4 with single precision fpu), teensy31 (cortex-m4 without fpu - only build test), nucleo_l073 (cortex-m0)
- singletest results are added to PR #2087 comments
- creating new core name Cortex_M7F_DP for a target with a double precision fpu
- adding new core name to arm.py to set compiler/linker flags to a double precision fpu when configured in target.json
- up to now: gcc wrote flag for a double precision fpu -> target with STM32F746 didn't run when using double variables - mcu has only single precision fpu
- changing gcc.py to use single precision for Cortex-M7 und double precision for Cortex_M7F_DP
tested with NUCLEO_F746, NUCLEO_F767 and build.py+make.py and exporting with project.py + compiling/flashing
- iar.py need a similar extention - I didn't change that yet because
- did not run at the moment - python exception
- currently worked on in PR #1948
libpath is not required for exporters, as they provide default paths.
This caused problems when paths are not correct for mbed tools, a project
fails to build as path is not found.
ARM and GNU compilers currently are in a mode where they will accept VLAs
in C++ as an extension. IAR does not accept them in C++.
Avoid potential portability surprises by making GCC warn, and
deactivating the extension in ArmCC.
This commit uses the previously introduced feature of generating
configuration data as a C header file rather than as command line macro
definitions. Each toolchain was modified to use prefix headers if
requested, and build_api.py was modified to set up the toolchain's
prefix header content using the data generated by the config system.
Tested by compiling blinky for GCC and ARMCC. I'm having a few issues
with my IAR license currently, but both ARMCC and IAR use the same
`--preinclude` option for prefix headers, so this shouldn't be an issue.
Note that at the moment all exporters still use the previous
configuration data mechanism (individual macro definitions as opposed to
a prefix header). Exporters will be updated in one or more PRs that will
follow.
Martin Kojtal
Jimmy Brisson
deepikabhavnani
Jammu Kekkonen
Cruz Monrreal II
ccli8
Martin Kojtal
Tony Wu
Christopher Haster
Cruz Monrreal
Evan Hosseini
TomoYamanaka
Sam Grove
Russ Butler
Brian Daniels
Sarah Marsh
Mihail Stoyanov
0xc0170
Olaf Hagendorf
Kevin Bracey
Bogdan Marinescu