PR #6270 added a parameter which allows the user to decide in case of an error or warning to print the output as a link.
This extension of this option also prints the ARM-GCC output in a link format.
A bug, #6755, was the result of the `subtract_basepath` function not
being applied to a resources object's children (it's features). This PR
fixes this bug by moving this functionality into the resources class.
Then, I applied the `subtract_basepath` method to the children resource
objects recursively. This has been tested on Partnerbeta and is to
upstream the fix.
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
Per default mbed compile prints errors/warnings on output not in a link format, therefore it is not possible to click, i.e. in an IDE, on the errors/warnings and jump to the position in the file.
The settings parameter lets you decide in witch format do you want to have it.
If it is enabled then the output will look like:
[Error/Warning] [absolute\path\to\file.ext]:[line]:[column]: [msg]
with this format nearly every common known IDE can deal with this link and lets you jump to the file
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.
This fixes an issue where the absolute path causes a file error if the
compiler paths are configured incorrectly. It uses a relative path
instead now (the files appears to be in the default search path).
This makes use of the reports generated by the building of tests to
prevent output from interleaving when the build is parallelized. This
required some changes to memap to return a generated string from
the 'generate_output' function. I also had an option to stop the prints
from memap to prevent text from interleaving
The 'silent' option has always been present in the toolchains API, however
it did not actually stop anything from being printed. Instead, it just
changed what was added to the build log. This make the 'silent' stop all
prints, but ensures that the output for the toolchain is still preserved
and accessible via the 'get_output' function.
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.
This commit fixes an issue where the output from memap.py was not
consistent across all output formats. This issue stemmed from the fact
that a few important calculations were being performed at output
generation time. This has been moved to the 'parse' function and saved for
future use by the 'generate' functions.
Because this commit saves more data to the MemapParser instance, there
were some name collisions. The public member 'mem_summary' has been
renamed to 'mem_report'. 'mem_report' contains the data structure used by
the json generator. This includes both the section data and the memory
summary. The 'mem_summary' member now just contains the summary. The
summary includes total allocated heap, total static RAM, etc.
Makes several broad changes:
- removes dead code that dealt with the online build system
- replaces export function with a much simpler one that:
- does not copy any sources
- the zip file hits the disk
- the mbed_config.h hits the disk
- the project files hit the disk
- nothing else hits the disk
- exporters use Resource object scanned with a toolchain
- progen exporters don't optionally build a project instead they have a
build function that may be called afterwards
- much of the code passes pylint (have a score of 9 or above):
- project.py
- project_api.py
- export/__init__.py
- export/exporters.py
- test/export/build_test.py
Keep track of the current size allocated, maximum size allocated,
number of allocations, failed allocations and total size allocated for
both GCC and ARM. Report the maximum size allocated at the end of
testing.
Also, add a test to verify heap metrics are working as expected.
The output of the GCC compiler is such that the toolchain regex sometimes
got hung up on the ':' charcter being printed in front of the drive letter when
running on Windows. This PR changes the matching logic to be more flexible
by using 'search' to check the entire string for a match, not just the
beginning of the string.
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)
This commit includes
- Changing build option parameter from -O2 to -Os to reduce flash size of the
final binary pacakge.
The original parameter of -O2 is kept to circumvent the error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762 .
But this error has been long fixed and released in latest 4.9.x GCC compiler.
This change is necessary to reduce the generated binary size of mbed Client component to
avoid problem of getting images over 512 kB which is causing application to crash because of
Configuration Store problem https://github.com/ARMmbed/configuration-store/issues/21
It's nicer to be compatible with the standards.
I have added one more field to the description of each function:
Side effects. This feild contains the expected side effects of
running a particular method. If the side effects of a method are
None, it is expected that the function does not change anything in
any envoronment and that running it multiple times with the same
arguments will produce the same result every time. That is when
Side effects is non, the method is expected to be pure.
The methods themselfes do nothing within the abstract base class
mbedToolchain. This change enforces that toolchains do not call
these methods that contain no implementation.
The mbedToolchain class calls many members of it's subclasses, expecting
them to implement a particular API. This change adds a requirement to
each subclass that requires them to implement this expected API.
The API consists of these methods:
- parse_dependencies
- parse_ouptut
- get_config_option
- compile_c
- compile_cpp
- link
- archive
- binary
This commit adds a check for configuration data changes. If a change in
configuration data is detected, all the sources in the tree are rebuilt.
This is a fix for #2073. #2162 was originally proposed as a fix, but it
was agreed that `--preinclude` is a more convenient way to include
configuration data, since it can be used to change the behaviour of
source files that don't include "mbed_config.h" directly, which is a big
advantage when importing 3rd party source trees. Compared to #2162, this
commit has the disadvantage of rebuilding all the source files if a
configuration change is detected, but it was agreed that the advantage
of using `--preinclude` outweighs the disadvantage of the increased
compilation time.
Remove special case targets which have floating point enabled in
Newlib Nano from gcc.py. To enable floating point printf/scanf
for a target configure it to use the 'standard' default build in
targets.json rather than 'small'.
when in target.json "default_build": "small" is configured
- build.py+make.py
- uses linker option --specs=nano.specs
- macro MBED_RTOS_SINGLE_THREAD is defined
- exporting with project.py + make Makefile
- doesn't use the linker option --specs=nano.specs
- doesn't contain macro MBED_RTOS_SINGLE_THREAD
- 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.