When overriding the OUTPUT_EXT variable in compilation configuration,
bugs appear:
* The bin variable is not None as the 'elf' string is not interned.
* When that is fixed, the function returns None instead of returning the
path of the ELF file.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
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
inc paths might be a list or might not be (just single string). If they don't, we are ending up with non valid include paths (one letter include paths).
This as result would not compile.
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.
An earlier patch in this series relies on the assumption that all
toolchain construction goes through `prepare_toolchain`. This is still
not the case. The only remaining user of the `mbedToolchain` object that
does not go through `prepare_toolchain` is the static analysis scanner.
It's basically dead-code at this point. I say we remove it. So this
patch removes it.
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.
Resolves the github issue #3790: Blinky fails to build (on Mac) after
addition of linker script preprocessing feature. Paraphrasing, this
issue is that Homebrew on mac does not install `arm-none-eabi-gcc` in
the same location as `arm-none-eabi-cpp`, the C Pre-Processor. The tools
prior to this commit, and after turning on the pre-processing of the
linker-script will fail on any Mac homebrew installed toolchains.
This commit resolves the above issue by allowing the toolchain's path to
the executable to remain empty after a call to `check_executable`. When
this path is empty, the tools will search the PATH environment variable
for the executable.
This allows us to define parts of the linker script outside of the
linker script itself. In particular, we are interested in restricting
ROM to a subsection.
* Adding Cortex-A support for gnuarmeclipse
* Preventing '-mthumb' from being added to Cortex-A builds.
Previously, both '-mthumb' and '-marm' were being supplied to the
compiler (in that order). Because '-marm' came last, the compiler
respected this option. This change makes it so '-mthumb' is added for
all 'Cortex-M' targets only.
* Renaming to capital .S for Eclipse compatibility
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.