We disable C++ static destructors as best as possible in the various
toolchains, trying to eliminate unwanted destructor code. We don't want
to waste RAM or ROM on the C++-standard-specified behaviour of running
all statically-constructed objects' destructors in reverse order on
exit; we're never going to perform an orderly exit.
Techniques used include:
* `SingletonPtr` - makes an object be "lazily constructed" on first use,
and also eliminates its destructor. Lazy construction adds ROM+RAM
overhead.
* `__eabi_atexit` is stubbed out, preventing RAM usage by run-time
registration of static destructors.
* GCC has `exit` wrapped to kill shutdown code
* IAR has static destructors disabled in the compiler flags
Killing static destructors in the compiler is the optimum; if we only
stub out `__eabi_atexit`, the compiler is still inserting calls to it,
and referencing the destructors in those call.
Clang 8 added the compiler option `-fno-c++-static-destructors` (and the
object attributes `[[clang::no_destroy]]` and
`[[clang::always_destroy]]` for fine control).
We can hence enable that option in ARMC6 tool profiles, matching IAR.
This option appears to exist in ARM Compiler 6.11, but generates an
apparently spurious linker error about `EthernetInterface`. It works in
ARM Compiler 6.13, so this PR needs to wait until the compiler is
updated.
According to GCC man:
To use the link-time optimizer, -flto and optimization options should be
specified at compile time and during the final link. It is recommended
that you compile all the files participating in the same link with the
same options and also specify those options at link time.
Additionally, move the '-g3' flag out of 'common' flags in the debug
profile. Although the '-g' is correctly ignored by the linker, the
'-glevel' is not and causes a build error "ld: unrecognized option
'-g3'".
For GCC we're being cautious by passing the
`-fno-delete-null-pointer-checks`. This option prevents some
optimisation opportunities, so removing it can reduce code size.
One particular optimisation loss occurs in `Callback` where a test
similar to this occurs:
extern void myfunc();
inline void foo(void (*fnptr)())
{
if (fnptr) {
do A;
} else {
do B;
}
};
foo(myfunc);
With `-fno-delete-null-pointer-checks`, the compiler does not assume
that `&myfunc` is non-null, and inserts the "null check" - seeing if the
address is 0. But performing that test of the address is incorrect
anyway - if myfunc actually could be at address 0, we'd still want to do
A.
Anyway, we do not have an equivalent option enabled for either Clang or
IAR, and we have performed clean-ups avoiding issues with
apparently-null vector tables in Clang already, for example #10534.
Therefore it should(TM) be safe to remove the option for GCC. We do not
have general data or code at address 0, only vectors are likely to be
there, so it does not make sense to be globally restricting code
generation for that.
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
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.
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.
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.
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 😉.