On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik <j...@lambda.is> wrote: > > Hi, > > I am working on adding path coverage support to gcc/gcov and need to > develop a good testing strategy. > > So far I can reasonably well report on the uncovered path as such: > > paths covered 6 of 17 > path not covered: 2 8 3 4 > path not covered: 2 8 3 5 6 > path not covered: 2 8 3 5 7 10 > ... > > where the numbers are the basic blocks of the CFG, which can be seen in > the source listing with gcov -a, e.g.: > > #####: 6: while (low <= high) > %%%%%: 6-block 2 > %%%%%: 6-block 8 > > Some natural test would be to by hand determine the paths taken and > compare with the gcov output, like lines/branches/conditions are tested > today. Unlike the other coverages in gcov, paths work more like function > summaries and cannot be reasonably shown in the source listing, but the > basic block listing actually works quite alright. > > The problem is testing. If gcc would re-number the basic blocks then > tests comparing hard-coded test paths would break, even though the path > coverage itself would be just fine (and presumably the change to the > basic block indices), which would add an unreasonable maintenance > burden. If anything, it feels very fragile to write tests against the > basic block indices.
Problematic is usually when early canonicalization changes the direction of a branch which affects the block IDs of the true/false destinations (and their downstream blocks). > On the other hand, if it can be expected that the same code should > always yield the same CFG, the same BBs, and the same BB indices then I > would happily test against them. I suppose this makes the basic blocks > basically a public interface, which granted feels odd. > > If you have any good idea on how to test paths in a robust way please > let me know. Is there enough info to print a path like the following? path not covered: t.c:2(true) t.c:4(false) t.c:11(true) ... instead of printing (condition destination?) block IDs? Richard. > > Thanks, > Jørgen
