Get GCOV results for kmem
iankronquist opened this issue · 15 comments
Right now I get this garbage after running the commands in make run-tests:
gcov kmem.gcno
kmem.gcda:stamp mismatch with notes file
File 'kernel/libk/kmem.c'
No executable lines
Removing 'kmem.c.gcov'
This is BS.
I have a hack which addresses this on the multitasking branch, but I don't like it.
@awensaunders if you're interested in helping this should be relatively easy. It requires researching gcov and changing how the tests are compiled in the Makefile. You'll get experience with a cool tool for measuring code coverage and with testing.
(Pro tip: employers love it when you bring up testing in an interview.)
gcov seems to be super particular about the version of gcc used to compile the code (and isn't backwards compatible). As the tests are compiled with llvm/clang, matching the version seems to be near-impossible. I could fix the problem by forcing a download of an older (clang compatible) version of gcov potentially, but I am not sure I like that. If you need integration with another tool that interfaces with gcov, then that could be the right move though.
Is there a particular reason that clang is used for the tests?
It's relatively easy to get the desired output from the code coverage files compiled with clang, if they are parsed by llvm-cov. However, the testfiles are also measured. The kmem.c.gcov is overwritten with data from the test file because of the names being the same. I'm not sure why the testfiles have coverage-testing in the first place.
@Herbstein the theory was that clang gives better warnings, but now that we have a newer GCC that isn't as important. I believe that what you say is correct. I'm told that @awensaunders is on vacation, so if you want to take this and run with it, go right ahead!
Yeah. I currently have 128kbps cell service here in Canada (and no public Wi-Fi)... Not much use, I'm afraid. I can take a look when I have decent connectivity in a week or so, but if @Herbstein wants to take care of it, then that's awesome.
On Jun 17, 2016, at 17:02, Ian Kronquist notifications@github.com wrote:
@Herbstein the theory was that clang gives better warnings, but now that we have a newer GCC that isn't as important. I believe that what you say is correct. I'm told that @awensaunders is on vacation, so if you want to take this and run with it, go right ahead!
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
I've gotten it to a point where I can generate *.gcov files for both the tested files and the test files themselves. I still have no clue why the test files are coverage-checked, but I might be missing something. The test files have been renamed to *_tests.c.
@Herbstein it may have to do with the hacky way I access global variables in the tests -- by #including the C file not the headers. If you can think of a better way to do this I am all ears.
Wouldn't that be fixed by moving the global variables to the header, and just including that?
@Herbstein the headers are included in multiple places, so that would cause another problem. Additionally, some of the globals are static, so you can't just declare extern int some_global_var;.
Christ. Alright. I do generate seperate coverage files, so we could theoretically delete the ones we don't need. It isn't optimal, but it would work.
That'll do.
Are the kmem_stubs.c.gcov files used, or should I also delete those?
Nope, those aren't used. They are just wrappers around malloc and free for the most part.