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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
