| Summary: | Valgrind tool should also include functionality of code coverage. This will help the developer communitiy to use a single tool for memcheck as well as for code coverage. | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Suresh <sureshsu> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | andrew.pennebaker |
| Priority: | NOR | ||
| Version First Reported In: | 2.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Suresh
2004-02-24 09:48:08 UTC
Has this wish been given up ? I've worked on it in the past, but there's a difficulty. Valgrind only sees the original program in small chunks as they're executed. Thus it is easy to identify which instructions (and thus which lines of code) have executed. But it's much more difficult to work out which instructions (and thus which executable lines of code) have not been executed. (In comparison, a compiler adding profiling instrumentation can see all the source code, so it doesn't have this problem.) Without knowing which lines have not been executed, you can't compute the testing coverage percentage, which is a big deficiency. And the only way for the user to know which lines haven't been executed is to search manually through the source code once it has been annotated, which is a huge pain. The only way to get the info about executable lines is to use the debugging information. However, I found that the debugging information produced by various versions of GCC to be somewhat unreliable, enough that the output produced by my coverage tool wasn't good enough. So, unless someone comes up with some new ideas, I don't think this will happen. My understanding of such a tool is that it should consist in:
1- a module which produces, after each run, a report containing all covered lines,
2- a module that merge run reports against executable lines of the exe.
3- optionaly, a module that produces advanced reports like coverage rate (by file, by function / method, by class...).
What you say is that part 1 is easy and we miss part 2 (unreliable debugging information). Is that right ?
Even if part 2 is needed to provide a proper code coverage tool, I would be interested in part 1.
I also would like to know which debugging information you miss (I don't know which gcc tool can help us and I don't know if you have looked for this tool).
Thanks
If you just want part 1, use Cachegrind. Its "Ir" (instruction read) events correspond to the number of instructions executed. So if you run it and then use 'cg_annotate --show=IR' you'll get what you want. My coverage tool was able to do part 1 (annotating executed lines) and part 2 (merging results from multiple executions), but not part 3 (percentage coverage information), which I consider a crucial part for any coverage tool. +1 |