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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207866 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204863 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194616 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194454 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194451 91177308-0d34-0410-b5e6-96231b3b80d8
