| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
llvm-cov was truncating numbers that were larger than a particular
fixed width, which is as confusing as it is useless. Instead, we use
engineering notation with SI prefix for magnitude.
llvm-svn: 237307
|
| |
|
|
|
|
| |
Patch by Vanderson M. Rosario. Thanks!
llvm-svn: 232443
|
| |
|
|
|
|
|
|
| |
This makes the reader check the endianness of the object file its
given and behave appropriately. For the test I dug up a really old
linker and created a ppc-apple-darwin file for llvm-cov to read.
llvm-svn: 232422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code was casting regions of a memory buffer to a couple of
different structs. This is wrong in a few ways:
1. It breaks aliasing rules.
2. If the buffer isn't aligned, it hits undefined behaviour.
3. It completely ignores endianness differences.
4. The structs being defined for this aren't specifying their padding
properly, so this doesn't even represent the data properly on some
platforms.
This commit is mostly NFC, except that it fixes reading coverage for
32 bit binaries as a side effect of getting rid of the mispadded
structs. I've included a test for that.
I've also baked in that we only handle little endian more explicitly,
since that was true in practice already. I'll fix this to handle
endianness properly in a followup commit.
llvm-svn: 232346
|
| |
|
|
|
|
|
|
| |
As of r231908, the test I added in r231902 actually gets run - but I'd
checked in a stale version of the input so it didn't pass. Fix the
input and un-xfail the test.
llvm-svn: 231911
|
| |
|
|
| |
llvm-svn: 231902
|
| |
|
|
|
|
| |
This format's easier to understand and update by hand.
llvm-svn: 231686
|
| |
|
|
|
|
|
|
| |
This code didn't really make sense as is. If a filename is passed in,
the user obviously wants the coverage *for that file*, not *for
everything*.
llvm-svn: 229217
|
| |
|
|
|
|
|
| |
It's not entirely clear to me what this field was meant for, but it's
always false. Remove it.
llvm-svn: 228034
|
| |
|
|
|
|
| |
Test causes buildbot failures.
llvm-svn: 218676
|
| |
|
|
|
|
|
|
| |
This commit adds a test which checks that the functions defined in header files will get associated with the header files rather than the source files in the reports.
Differential Revision: http://reviews.llvm.org/D5489
llvm-svn: 218673
|
| |
|
|
|
|
|
|
| |
This commit fixes llvm-cov's function coverage metric by using the number of executed functions instead of the number of fully covered functions.
Differential Revision: http://reviews.llvm.org/D5196
llvm-svn: 218672
|
| |
|
|
|
|
|
|
| |
If we have multiple coverage counts for the same segment, we need to
add them up rather than arbitrarily choosing one. This fixes that and
adds a test with template instantiations to exercise it.
llvm-svn: 218432
|
| |
|
|
|
|
|
| |
Since llvm-cov shows the source file in its output, be careful about
potentially matching the check lines themselves.
llvm-svn: 218138
|
| |
|
|
|
|
|
| |
Uncovered lines in the middle of a covered region weren't being shown
when filtering to a particular function.
llvm-svn: 218109
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a call to sys::fs::equivalent that should've been to
CodeCoverageTool::equivalentFiles, which lets us restore the test of
r217476 that was removed in r217478.
This reverts r217478, but the test works this time.
llvm-svn: 217646
|
| |
|
|
|
|
|
| |
It appears this code was completely untested, so using ArrayRef wrong
didn't break anything obvious.
llvm-svn: 217476
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
clang's pgo.
This commit expands llvm-cov's functionality by adding support for a new code coverage
tool that uses LLVM's coverage mapping format and clang's instrumentation based profiling.
The gcov compatible tool can be invoked by supplying the 'gcov' command as the first argument,
or by modifying the tool's name to end with 'gcov'.
Differential Revision: http://reviews.llvm.org/D4445
llvm-svn: 216300
|
| |
|
|
|
|
|
|
|
|
|
| |
If the source files referenced by a gcno file are missing, gcov
outputs a coverage file where every line is simply /*EOF*/. This also
occurs for lines in the coverage that are past the end of a file that
is found.
This change mimics gcov.
llvm-svn: 208149
|
| |
|
|
|
|
|
|
| |
In gcov, there's a -n/--no-output option, which disables the writing
of any .gcov files, so that it emits only the summary info on stdout.
This implements the same behaviour in llvm-cov.
llvm-svn: 208148
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Reading line tables in llvm-cov was pretty broken, but would happen to
work as long as no line in the table was 0. It's not clear to me
whether a line of zero *should* show up in these tables, but deciding
to read a string in the middle of the line table is certainly the
wrong thing to do if it does.
I've also added some comments, as trying to figure out what this block
of code was doing was fairly unpleasant.
llvm-svn: 207866
|
| |
|
|
|
|
|
|
| |
GCOV provides an option to prepend output file names with the source
file name, to disambiguate between covered data that's included from
multiple sources. Add a flag to llvm-cov that does the same.
llvm-svn: 207035
|
| |
|
|
|
|
|
|
|
| |
Functions may in an instrumented binary but not in the original source
when they're inserted by the compiler or the runtime. These functions
aren't meaningful to the user, so teach llvm-cov to skip over them
instead of crashing.
llvm-svn: 204863
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, when a path in a gcno file included a directory, we would
emit our .gcov file in that directory, whereas gcov always emits the
file in the current directory. In doing so, this implements gcov's
strange name-mangling -p flag, which is needed to avoid clobbering
files when two with the same name exist in different directories.
The path mangling is a bit ugly and only handles unix-like paths, but
it's simple, and it doesn't make any guesses as to how it should
behave outside of what gcov documents. If we decide this should be
cross platform later, we can consider the compatibility implications
then.
llvm-svn: 200754
|
| |
|
|
| |
llvm-svn: 200741
|
| |
|
|
|
|
|
|
| |
When gcov is run without gcda data, it acts as if the counts are all
zero and labels the file as - to indicate that there was no data. We
should do the same.
llvm-svn: 200740
|
| |
|
|
|
|
|
|
|
|
|
| |
Similar to the file summaries, the function summaries output line,
branching and call statistics. The file summaries have been moved
outside the initial loop so that all of the function summaries can be
outputted before file summaries.
Also updated test cases.
llvm-svn: 197633
|
| |
|
|
|
|
|
|
|
|
|
|
| |
File summaries will now be optionally outputted which will give line,
branching and call coverage info. Unfortunately, clang's current
instrumentation does not give enough information to deduce function
calls, something that gcc is able to do. Thus, no calls are always
outputted to be consistent with gcov output.
Also updated tests.
llvm-svn: 197606
|
| |
|
|
|
|
|
|
|
| |
This will cause llvm-cov to output branch counts instead of branch
probabilities. -b must be enabled.
Also updated tests.
llvm-svn: 197594
|
| |
|
|
|
|
|
|
|
| |
Outputs branch information for unconditional branches in addition to
conditional branches. -b option must be enabled.
Also updated tests.
llvm-svn: 197432
|
| |
|
|
|
|
|
|
|
|
|
| |
This option tells llvm-cov to print out branch probabilities when
a basic block contains multiple branches. It also prints out some
function summary info including the number of times the function enters,
the percent of time it returns, and how many blocks were executed.
Also updated tests.
llvm-svn: 197198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to gcov, llvm-cov will now print out the block count at the end
of each block. Multiple blocks can end on the same line.
One computational difference is by using -a, llvm-cov will no longer
simply add the block counts together to form a line count. Instead, it
will take the maximum of the block counts on that line. This has a
similar effect to what gcov does, but generates more correct counts in
certain scenarios.
Also updated tests.
llvm-svn: 196856
|
| |
|
|
| |
llvm-svn: 196632
|
| |
|
|
| |
llvm-svn: 196609
|
| |
|
|
| |
llvm-svn: 196530
|
| |
|
|
|
|
| |
And add the proper fix.
llvm-svn: 196367
|
| |
|
|
|
|
|
| |
This currently breaks clang/test/CodeGen/code-coverage.c. The root cause
is that the newly introduced access to Funcs[j] is out of bounds.
llvm-svn: 196365
|
| |
|
|
|
|
|
| |
The function checksums are hashed from the concatenation of the function
name and line number.
llvm-svn: 196358
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of permanently outputting "MVLL" as the file checksum, clang
will create gcno and gcda checksums by hashing the destination block
numbers of every arc. This allows for llvm-cov to check if the two gcov
files are synchronized.
Regenerated the test files so they contain the checksum. Also added
negative test to ensure error when the checksums don't match.
llvm-svn: 195191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the hazy gcov documentation, it appeared to be technically
possible for lines within a block to belong to different source files.
However, upon further investigation, gcov does not actually support
multiple source files for a single block.
This change removes a level of separation between blocks and lines by
replacing the StringMap of GCOVLines with a SmallVector of ints
representing line numbers. This also means that the GCOVLines class is
no longer needed.
This paves the way for supporting the "-a" option, which will output
block information.
llvm-svn: 194637
|
| |
|
|
|
|
|
|
|
|
| |
This test compares the output of llvm-cov against a coverage file
generated by gcov. Currently, llvm-cov does not work on certain
platforms (namely big-endian architectures such as PowerPC, among
others). These platforms are marked as XFAIL for now, but will be fixed
later.
llvm-svn: 194616
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r194451.
Not sure why the tests are failing on the buildbot. They run fine on my
local machine. Could it possibly be because of the endianness of the
architectures? The GCNO and GCDA files are little-endian encoded, and
llvm-cov expects it to remain that way. Is this a safe assumption?
llvm-svn: 194454
|
| |
|
|
|
|
| |
Also updated test files that were generated from this change.
llvm-svn: 194453
|
| |
|
|
|
|
|
|
|
| |
This test compares the output of llvm-cov against a coverage file
generated by gcov. Since the source file must be in the current
directory when reading GCNO files, the test will first cd into the
Inputs directory.
llvm-svn: 194451
|
| |
|
|
|
|
| |
This reverts commit 9cacd131c22b888303cb88e9a3235b2d7b2f19a1.
llvm-svn: 194039
|
|
|
This test compares the output of llvm-cov against a coverage file
generated by gcov.
llvm-svn: 194038
|