* Fixed wrapper functions for IAR
* Fixed and renamed profile to minimal-printf.json
* Moved minimal-printf under platform
* Removed minimal-printf/mbed_lib.json
* Modified exporter template to work with partial profile
* Prevented optimization of printf to avoid compiler function substitution
This brings massive ROM savings, and allows to use debug builds
also with larger applications (for. ex. Mesh stack).
Diff. for mbed-cloud-client-example with Wi-Sun stack.
Total Static RAM memory (data + bss): 85120(-216) bytes
Total Flash memory (text + data): 592668(-329296) bytes
Do not specify the debug level for develop and release profiles. Instead
rely on the compiler to choose sensible default (-g2). Note that -g1 is
minimal debugging information and does not include structure definitions
which quite heavily reduces debugging experience.
For develop and release profiles this results in elf file containing
structure definitions. This does not impact debug profile as it already
did use -g3 which is the highest debug level.
Compatible debuggers (eg. gdb, SEGGER Ozone) can use the extra information
to provide better debugging experience. For example, when compiled .elf is
loaded in gdb, this change makes it trivial to access internal RTX data.
Without this change on develop profile:
(gdb) print osRtxInfo.thread.run
'osRtxInfo' has unknown type; cast it to its declared type
With this change on develop profile:
(gdb) print osRtxInfo.thread.run
$1 = {curr = 0x20014F04, next = 0x20014F04}
When packing data into multiple regions using the `.ANY` directive,
the linker can accidentally overfill an area.
This doesn't normally happen because it defaults to
`--any_placement=worst_fit`, which puts data in the region with
most space.
When we prioritise regions with `.ANY1`/`.ANY2`, it may totally fill
an area, then fail to leave enough space for linker-generated veneers.
We've just seen this error with the new K64F linker map.
Adding `--any-contingency` makes it lower priority when a region is
98% full, avoiding this error.
The option should not have any effect on targets with scatter files
without prioritised `.ANY` directives.
Due to some historical reasons ARMC 5 compiler behaves very
differently compared to others (GCC, IAR, ARM C 6) as it optimizes
performance rather than size (like the others).
All compilers should behave the same way with the same profile,
thus ARM C 5 should also drive towards size (space).
Lots of target code, STM in particular, uses the `register` keyword, so
it'll take a little while to clean up. In the interim, some builds are
producing a lot of warnings. Suppress the warning for now, as `register`
remains legal C++14 and C11, despite C++14 deprecating it.
C++17 removes `register`, so code will need to be cleaned before any
further C++ version update.
Clang warns about reserved user-defined literals by default. This
warning is not terribly helpful; compilers aren't normally in the
habit of warning about use of reserved identifiers. It can interfere
with, for example, deliberate emulation of a future standard
language feature.
The warning was promoted to an error in an mbed client build, due to a
non-C++11 "%s"name occurring in a macro. But the macro itself was never
invoked, so the misinterpretation as C++11 caused no problems other than
this warning. Killing the warning will let that code build on ARMC6.
The code already built on GCC and IAR.
If that macro ever was used, then a separate error about operator ""
name not being defined would be generated, on all 3 toolchains.
Since the year dot GCC has been passed the `-fno-builtin` option, which
eliminates all compiler knowledge of the C library, even down to basic
stuff like `memcpy` or `memset`, potentially inhibiting quite a lot of
optimisations.
Remove the option to re-enable the optimisations.
There is no record in the source as to why the option is present - maybe
we'll find out by trying to remove it. If necessary, it could be
selectively turned back on for particular functions.
printf was called from ISR when sleep tracing was enabled. Issue was
captured only in debug profile.
Printf is not allowed from ISR context and issues like this should be
trapped in case of debug profiles as well.
Main thread in Mbed OS is statically allocated and was not available in call
stack of Keil MDK. The RTX5 kernel requires statically allocated thread
information objects that are placed into a specific section to enable RTOS
thread awareness in Keil MDK. This fix is to keep main thread in specific
section of memory.
### Description
Arm compiler 5 builds with "short" enums and "short" wchars. This means
that C/C++ enums will be packed into the smallest power of 2 number of
bytes by the compiler and the `wchar_t` is 2 bytes. Arm compiler 6
defaults to packing enums into 4 bytes and `wchar_t` is 4 bytes.
Further, Arm Compiler 5's `-O0` (no optimizations) bulids will actually
do some amount of optimizing, similar to Arm Compiler 6's `-O1`. I have
switched the debug profile to `-O1` for maximum compatibility with our
prior behavior.
NOTE: "Compatibilize" is a word
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change
Quite a few of the scatter files are not (yet) aligned to 8-byte
boundaries and therefore the removal of legacy alignment feature
(which is under deprecation warning, but it actually not YET
deprecated) broke quite a few builds to this error:
Error: L6244E: Exec region RW_IRAM1 address (0x200001ac) not aligned on a 8 byte boundary.
We must bring this option now back to fix the builds.
This option to ld (--legacyalign) can only be removed once all of
the scatter files have been fixed.
By default IAR generates "transfer of control bypasses initialization"
warnings for C code - it's a legal construct that frequently occurs when
doing Linux-style "goto error". Many occurrences in Nanostack.
Suppress the warning for C only, to align with GCC and ARMCC. Have to
take care not to put it in the "common" section, as this would suppress
it for C++, where it actually is illegal.
### Description
Full paths in the map file are required to have correct memap parsing.
This PR adds the option `--show_full_path` to ARMC6 in every profile.
This option only affects the map file output, so it's safe to add.
This allows minimal debugging and allows tools like
mbed-os-linker-report to work properly.
Because debugging info is kept in .elf file and not flashed to device
there is no side effects to flash sizes.
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
The extra space between "--no_wrap_diagnostics" and "-e" is inconsistent with the development and release targets.
It bugs people (like me) that have little OCD tics 😉.