[PATCH] Code coverage tool that uses the new coverage mapping format and clang's instrumentation based profiling data

[Alex L]

2014-07-15 14:40 GMT-07:00 Justin Bogner <mail at justinbogner.com>:

> Alex Lorenz <arphaman at gmail.com> writes:
> > The patch provides the initial implementation of the updated code
> > coverage tool that uses clang's instrumentation based profiling data
> > (the -fprofile-instr-generate option) and the new coverage mapping
> > format.
> >
> > The gcov compatible tool is still there. To invoke the new tool, pass
> > the 'show' or 'report' command as the first argument to llvm-cov.
> >
> > The show command displays the code coverage information for a set of
> > source code files of a program. Some of its options follow:
> >   -show-expansions - Show macro expansions
> >   -show-instantiations - Show template/static functions instantiations
> >   -show-regions - Show region markers
> >   -show-line-counts - Show execution counts for each line (enabled by
> default).
> >
> > The report command displays a couple of code coverage metrics for
> > files/functions in a concise table.
>
> I'll review this more thoroughly soon, but I have a couple of high level
> comments:
>

> 1. It would probably be easier to understand this if it was split into
>    two patches: first move the gcov compatible code to its own file and
>    update llvm-cov to be a wrapper that always calls into that, and then
>    add the new-style support.
>
> 2. The semantics for choosing whether to be gcov-compatible are a bit
>    confusing. I can see the value of "no recognized command" implying
>    compatible behaviour, but going forward we should encourage a saner
>    API. Consider:
>
>    - If invoked as gcov (ie, argv[0] is or ends in "gcov"), always be
>      gcov compatible.
>    - Provide a "gcov" command in addition to "show" and "report", which
>      invokes into gcov for the rest of the command line.
>    - If no command matches fall back to gcov (perhaps with a warning
>      that this usage may be dropped in the future)
>

This sounds like a much better approach than the current one, I will update
the patch with the new logic and split it into two.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140715/197576ef/attachment.html>