On Sat, Jul 7, 2018, 2:33 PM Chris Johns <ch...@contemporary.net.au> wrote:
> On 5 Jul 2018, at 3:07 am, Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chr...@rtems.org > > <mailto:chr...@rtems.org>> wrote: > > > > How does this fit into the RTEMS Tester tool? > > > > > > If you want to run gcov or lcov on uninstrumented executables, then > covoar has > > to read gcno and write gcda files. And we have to then run gcov or lcov > as > > normal. > This is just a description of how it works. Not a particular change. > > > It is the path to another report format. > > I am not sure I understand how we make this work and how we support the > user. Is > this an option to 'rtems-test'? > > The aim of the 'rtems-test' command is to provide a documented user > interface. > Providing direct access to covoar adds more documentation and complication > to > the test tool. For example how does the user wanting gcov output get to the > trace files? The user would need to step into how we implement coverage > and that > is an interface we will not document and change. > I wouldn't want a user to invoke covoar directly. It is just a coverage reporting variant at this point. I doubt it will ever be the default report format because we have details in the native reports that I don't think you can get ever with gcov. I think the native format is closer to what you would use on an analysis for the highest level of coverage. The gcov reports have their own positive attributes. Particularly when you combine them with something like gcovr which can generate xml. > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
