[U-Boot] [PATCH] kconfig: add CONFIG_CC_COVERAGE

[Tom Rini]

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 at 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 at 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-eclipse-gcc-and-gcov/
> 
> 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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180409/7e3e4cb4/attachment.sig>