|
From: Benjamin M. <be...@me...> - 2007-08-16 18:25:48
|
On Aug 16, 2007, at 3:25 PM, Josef Weidendorfer wrote: > On Thursday 16 August 2007, Benjamin Meyer wrote: >> The last few nights I have been hacking on a coverage tool for >> valgrind. I have been spending most of the time learning just how to >> do this. Thanks for all of the docs, I really appreciated it. The >> main reason I wanted to write this was because the existing solutions >> out there require too much extra work and why do all that when >> valgrind could. The other, bigger reason is that using cachegrind >> will not give you branch information and will mislead you by saying >> that the following code has 100% coverage when x is only ever 10. >> >> if(x > 0) >> do() >> bar(); >> >> Below is the current output of this tool as it is tonight (run on the >> attached main.c file with three args) . You pass it the file you >> want it to record and at finish it outputs all of the line numbers >> with the branch reports embedded. This will go to the output file. >> I was thinking that another tool would run on the data and source >> files to produce output best for the language the source is in and >> for the output formats (html?). Should I try to output in the same >> fileformat as callgrind or ...? > > Hi Benjamin, > > In general, I vote for the callgrind format ;-) IMHO, it should be > able to > express the kind of information your tool is collecting. > > However, can it be that callgrind already collects the same kind of > branch information with --collect-jumps=yes ? Nice, didn't know about that option. I will have to investigate it (but from the sounds of it, it makes my work obsolete) > IMHO the biggest missing piece for a good coverage tool is, as Nick > points out, > that you need to relate the real executed instructions/lines/ > branches to > all existing instructions/lines/branches, also in not executed code > (probably only for code where debug info is available). > > Of course, that can be done in a separate, static step with some > script which > interpretes the debug information. At least for C++ I was planning on using Roberto Raggi's C++ parser for combining the two. > Loading this together with callgrinds output into KCachegrind > should be able > to give the coverage figures. AFAICS, this needs some improvements for > derived event types in KCachegrind (e.g. support "/" operator), and > perhaps > some additions for the visualization. > > Currently, I am working a little bit on KCachegrind/KDE4 (e.g. port to > QGraphicsView), so I could invest some time looking into this. > > Josef Although it would be neat to have in KCachegrind, a command line too that generates a report is probably much more useful. Code coverage is usually run on top of autotests in an automated fashion and the report is generated nightly. Talking with some guys from KDE the ideas was to use it like that and integrate it into http:// www.englishbreakfastnetwork.org/ -Benjamin Meyer |