
On Mon, Apr 09, 2018 at 10:01:59AM +0200, Christian Gmeiner wrote:
Hi
2018-04-08 16:30 GMT+02:00 Tom Rini trini@konsulko.com:
On Thu, Mar 29, 2018 at 09:49:30AM +0200, Christian Gmeiner wrote:
Make it possible to use gcc code coverage analysis.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com
.gitignore | 4 ++++ Kconfig | 8 ++++++++ Makefile | 6 ++++++ 3 files changed, 18 insertions(+)
diff --git a/.gitignore b/.gitignore index 29757aa51e..f1b801579c 100644 --- a/.gitignore +++ b/.gitignore @@ -85,3 +85,7 @@ GTAGS *.orig *~ #*#
+# gcc code coverage files +*.gcda +*.gcno diff --git a/Kconfig b/Kconfig index 6670913799..f092f72b25 100644 --- a/Kconfig +++ b/Kconfig @@ -59,6 +59,14 @@ config CC_OPTIMIZE_FOR_SIZE
This option is enabled by default for U-Boot.
+config CC_COVERAGE
bool "Enable code coverage analysis"
default n
depends on SANDBOX
help
Enabling this option will pass "--coverage" to gcc to compile
and link code instrumented for coverage analysis.
We shouldn't need default n, as that is the normal default. And why is this only on SANDBOX?
The default thing will get fixed in V2. If we want to record code coverage on real hardware we need to add an infrastructure to store the generated analysis data. In the sandbox case this information is stored in the local filesystem (*.gcda). To get a feeling what may be needs to be done for the real target patch have a look at: https://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-e...
My goal is it to get some code coverage data for unit tests that are run in the sandboxed environment.
Is it okay for you to only cover the sandbox case or do you want/need the full blown solution?
While it would be cool to do this on real hardware, I guess that makes sense to do in a follow up. Thanks for explaining!