Stubs previously in UNITTESTS/target_h/ have the same names as
regular Mbed OS headers, intending to override the latter directly.
We move platform target_h stubs into
platform/tests/UNITTESTS/doubles/platform/.
Note: nvic_wrapper.h is normally implemented and used by Mbed targets
as needed. But as unit tests do not have a real target, we treat it
as a stub for the platform.
ARMCC provides __semihost via compat header. As CMSIS 5.8.0 removed this compat header,
we need to explicitly include it to fix definition missing error.
Reference: CMSIS 5.8.0 known issues and https://github.com/ARM-software/CMSIS_5/issues/1211
This fixes the error about redefinition of enable/disable irq. we need compat header because of
semihosting (not yet provided in CMSIS).
Previously a test executable was recognised as a single test by CTest.
However, test executables usually contain multiple test cases, the
results of the test cases should be individually reported. With our
previous setup we could miss test case failures that didn't cause the
executable to return an error code.
This commit uses gtest_discover_test to discover all test cases in a
test executable. This enables CTest to match test passes and failures
from the googletest binary output.
The CircularBuffer doesn't allow pushing zero elements; you must push at
least one. Update the CircularBuffer unit test to avoid invalid use of
the CircularBuffer.
On a target that doesn't support Firmware Update, compilation still works, and any attempt to call the Firmware Update API returns a runtime error which is good enough.
When building greentea tests, each test is an executable with its
own output binary path. This is also the case when a user project
produces multiple executables. But the current implementation of
post-build operations always assumes there's only one executable,
at the root of the build directory.
The post-build command depends on Mbed target, and it always takes
the the executable we build as an input file. To achieve this, we
let each Mbed target (that has a post-build command) define a function
function(mbed_post_build_function target)
which takes a CMake executable target as an argument from which it can
get its binary path using generator expressions. It generates and adds
to the passed executable target a post-build custom command.
Notes:
* The function name needs to be exact, because CMake only supports
literal function calls - CMake can't dereference a function name from
a variable. To avoid multiple definitions of this function, each Mbed
target needs to guard it with a macro to check if the user is
building this Mbed target.
* `mbed_post_build_function()` is a function, but it is usually
defined by another macro rather than a parent function, because
nesting functions would make many variables inaccessible inside the
innermost `mbed_post_build_function()`.
* There's no more need to force regenerate images. Previously, post-
build commands were custom *targets* which always got to run, so we
force regenerated images on every build to avoid patching an image
that's already been patched once on previous build. Now post-build
commands are custom *commands* of the same executable target, and they
are only run if the executable target itself is rebuilt.
We have a central collection of "stub headers", which makes reasoning
about dependencies rather difficult, as it forces every stub library to
depend on all available stub headers. The standard approach would be for
each stub library to expose its public headers, and its dependents to
explicitly specify a dependency on the stub library containing the
headers it needs. This is a more modular design than creating a
header-only monolith library. Move the platform stub headers from this
central library into the mbed-stubs-platform library to increase
modularity.
mbed-stubs-connectivity now depends on the mbed-stubs-platform because
it requires some headers which were moved to mbed-stubs-platform.
Previously the platform stub library depended on `mbed-headers`, which
is a collection of all available headers in mbed-os. To make it easier
to separate the library, only depend on the headers we're actually using.
Move the header-only mbed-headers-platform library the unit test stubs
depend on into the platform component directory. This makes the platform
stubs more self contained and improves composition of the library.
Move the platform stub library into the platform component directory.
This change is so we can avoid duplicating the mbed-os source tree in a
central UNITTESTS folder.
subprocess.PIPE is used to enable the parent process to communicate with
the subprocess via pipes, which mean all stdout and stderr messages are
captured and returned as part of Popen.communicate's result tuple.
In our case, we want to display the error messages on the console, so we
don't need to capture the output from stdout.
Example of a typical error message before this change:
```
Traceback (most recent call last):
File "platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/scripts/generate_mbed_image.py", line 197, in <module>
sign_and_merge_tfm_bin(args.tfm_target, args.target_path, args.non_secure_bin, args.secure_bin)
File "platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/scripts/generate_mbed_image.py", line 81, in sign_and_merge_tfm_bin
" secure binary, Error code: " + str(retcode))
Exception: Unable to sign musca_b1 secure binary, Error code: 1
```
Example of the error message after this change:
```
Traceback (most recent call last):
File "/mbed-os/tools/psa/tfm/bin_utils/wrapper.py", line 13, in <module>
import click
ModuleNotFoundError: No module named 'click'
Traceback (most recent call last):
File "platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/scripts/generate_mbed_image.py", line 194, in <module>
sign_and_merge_tfm_bin(args.tfm_target, args.target_path, args.non_secure_bin, args.secure_bin)
File "platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/scripts/generate_mbed_image.py", line 80, in sign_and_merge_tfm_bin
raise Exception("Unable to sign " + target_name +
Exception: Unable to sign musca_b1 secure binary, Error code: 1
```
This is a significant improvement as now you can see what the reason for
the failure was.
Move /val and /pal directories into /test_abstraction_layers directory
and combine into one CMake target, mbed-psa-tal. Moved into seperate
directory in order to have own CMakeLists.txt, rather than adding to
/TARGET_MBED_PSA_SRV CMake file.
Assumption that greentea test file is always named main.cpp is
incorrect. Updated mbed_greentea_add_test() macro to make TEST_SOURCES
parameter compulsory, which is used to specify greentea test
file(s). This allows tests to use C, or have a different name.
Therefore also updated all pre-existing greentea test CMake files to
explicity add main.cpp to TEST_SOURCES.
If one called mbed_trace_free() but continued using the trace (which
is a supported use case), the already freed tmp_data buffer was used
by tr_array().
This was spotted by Valgrind on some unit tests which do enable the
trace only temporarily for some of the tests.
Error being fixed in this PR:
--8<--8<--8<---
==5865== Invalid write of size 1
==5865== at 0x2639BB: mbed_trace_array (mbed_trace.c:569)
<...>
==5865== Address 0x5dc79d0 is 0 bytes inside a block of size 128 free'd
==5865== at 0x4C32D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5865== by 0x262723: mbed_trace_free (mbed_trace.c:192)
<...>
==5865== Block was alloc'd at
==5865== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5865== by 0x262548: mbed_trace_init (mbed_trace.c:162)
<...>
Typically when adding a unit test directory to a CMake project a check
will be used to ensure the subdirectory is added only if the following
are true:
* The BUILD_TESTING option is set to ON.
* The current CMake project is the top-level project.
The reason being, if a downstream project includes our project they
generally don't want to build our unit tests.
In mbed-os, we do correctly specify the above condition before adding
the central UNITTEST subdirectory, which fetches googletest and adds the
"stub" libraries the unit tests depend on. However, we only check if
CMAKE_CROSSCOMPILING is OFF (or undefined) before actually adding the
unit tests. This mismatched logic would lead to unexpected build
failures in various scenarios. One likely case could be: a downstream
project including mbed-os happens to set CMAKE_CROSSCOMPILING to
OFF/undefined for any reason (possibly to build its own unit tests).
mbed-os would go ahead and attempt to build its tests without fetching
googletest or adding the required stub targets.
To fix the issue replace the check for CMAKE_CROSSCOMPILING in the unit
tests with the same BUILD_TESTING idiom we use for adding the central
UNITTESTS subdirectory.
- Remove redundant cmake script as already added the CMake configuration file
- Remove redundant empty_baseline as it is no longer needed with the help of CMake configuration file
Lingkai Dong
Jaeden Amero
Martin Kojtal
Robert Walton
Chun-Chieh Li
mbedmain
Hari Limaye
Arto Kinnunen
Antti Kauppila
Tero Jääskö
Tymoteusz Bloch
Meano
Rajkumar Kanagaraj