[RFC] Debug info coverage tool (original) (raw)

September 17, 2024, 1:25pm 15

Maybe I didn’t understand. Looking first at the unoptimized object, we use that line table as the oracle of what source locations produced instructions. In the unoptimized object, we can map the variable’s scope’s PC range to a set of source locations, then reduce that set by removing the locations that precede the first definition of the variable. Variable coverage in the unoptimized object is necessarily 100% because we don’t emit PC ranges on variables at O0.

Looking at the optimized object, we could in principle have a lossless optimized line table (all lines from O0 are still represented). We could in principle have lossless variable coverage if the PC range on the variable spans the first-def to end-of-scope. If we are in that situation, coverage is still 100%.

However, even with a lossless optimized line table, we can discover variable-coverage losses simply because the variable’s liveness does not in fact span its entire scope, which is an artifact of optimization that we don’t really want to “fix.” The only way to achieve 100% coverage in this case is to artificially extend the variable’s lifetime.

And, even with a variable whose liveness does span its entire scope, we can also discover across-the-board losses due to source lines not represented in the optimized line table at all, because optimizations have correctly eliminated redundancies (for example). Again we do not want to “fix” this because the optimizations are doing exactly what we want.

So, there are two independent sources of lost coverage, that are not bugs, meaning that we are unlikely to achieve 100% coverage in the optimized build. And then there are losses in the line table due to bugs, and losses in variable coverage due to bugs. It appears that the proposed metric folds all these together?

That might be the best we can do, but I think it would be good to tease apart line-table losses from variable-coverage losses, if we can. (Maybe we can’t.)