[PATCH 00/12] Support gcov instrumentation

[Sebastian Huber]

On 01.07.22 03:19, Chris Johns wrote:
> On 29/6/2022 4:30 pm, Sebastian Huber wrote:
>> This patch set adds support to build the RTEMS libraries with gcov
>> instrumentation to get code and branch coverage.  There are some improvements
>> necessary in the build system to support different compiler flags for libraries
>> and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
>> build configuration option.
> 
> Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow
> provides?

The covoar uses uninstrumented code, so these two approaches are 
orthogonal. You could even use both approaches at the same time. This 
makes little sense, but you could do it.

> 
> If this enable is specific to GCC's gcov then maybe we should clearly label it
> as that and avoid overloading the term and any possible confusion that might
> bring. For example RTEMS_GCOV_CONVERGE?

It is not per se specific to GCC. Maybe we should name it 
RTEMS_COVERAGE_INSTRUMENTATION.

> 
>> The user can fine tune the build through the
>> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS,
>> COVERAGE_LINKER_FLAGS options.
> 
> How would the LTO fat options be added? Would the pattern for
> COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?

Do you have to specify the compiler flags also during linking if you use 
LTO?

> 
> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
> from an INI file?

Currently the OPTIMIZATION_FLAGS are used for all code (code for 
libraries and code for tests).  With this change you can build the 
libraries with -O0 and the tests with -O2 for example.

> 
> I think the changes to cppflags, cflags and cxxflags are nice and a great
> progression.
> 
>>   The gcov information is dumped after each test
>> case in a base64 encoded gcfn and gcda data stream.  It looks like this:
>>
>> *** BEGIN OF GCOV INFO BASE64 ***
>> bmZjZyAxMkJSAAAAL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
>> dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUAAAAB
>> DAAAAOOrF1pxp0aIPrK7wAAAoQHw////AAAAAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAAAAAQAAAAA
>> ...
>> srvAAAChAfD///8AAAABDAAAAMXOxS0Rhzqx6Old2wAAoQH4////AAAAAQwAAACYh8U9/rgJ5hMc
>> ig8AAKEB2P///wAAAAEMAAAAN3+9YAwMW8gTHIoPAAChAdj///8AAAABDAAAADAwMx4TuamFPrK7
>> wAAAoQHw////AAAAAQwAAACvassJzDNWd/lKs3wAAKEB8P///wAAAAA=
>> *** END OF GCOV INFO BASE64 ***
>>
>> On the host you can decode the block and pipe it through the gcov-tool to
>> produce the *.gcda files.  Example Python code:
>>
>> block = some regex stuff to get the block between the BEGIN/END OF ...
>> stream = base64.b64decode(block)
>> subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)
> 
> Nice. Could  rtems-test detect this and then run that command if available?

Yes, this could be an option. Another is to produce a JSON report and 
then run a second script.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/