How to get CFG used by SanitzerCoverage edge?


I have been experimenting with the SanitizerCoverage tool and I’m particularly interested in edge-level coverage. I tried applying this to some tests I have in a small project and everything makes sense except one function where a factory is being used. The closing brace is identified as not covered. I created the following basic example that exhibits similar behavior:


auto usesFactory(int size) → std::unique_ptr<std::vector> {
auto v = std::make_unique<std::vector>();
return v;

int main() {
auto v = usesFactory(5);

return 0;

If you compile and run this per the SanitizerCoverage documentation, you should see that there are multiple (three in my case) instances of missing coverage on the line for usesFactory()'s closing brace. I tried two things to figure out how to eliminate this: -fno-exceptions and adding an additional test where the mocked factory (taking the place of std::make_unique and reserve) throws an exception. In my actual test, -fno-exceptions removes all the missing coverage statements, but throwing an exception through “make_unique and reserve” doesn’t. Using -fno-exceptions in this code example only removes two out of three missing coverage statements.

Although I’m interested to know how to reach these edges, I’ve really been trying to find a way for clang to tell me the control flow graph it’s using when generating the instrumentation. I’ve tried the debug.DumpCFG static analysis tool, but that doesn’t seem to know anything about exceptions or any other surprising control flow that would generate these edges. Additionally, I tried clang++ … -emit-llvm -S main.cpp -o main.llvm; opt -dot-cfg main.llvm as well as just looking at assembly after the coverage instrumentation is added. Unfortunately I haven’t been able to make much sense of these and I don’t know if this is the best way forward anyway.

I would really appreciate any help identifying these mysterious edges or, even better, finding a way to see the CFG that clang is using when generating the coverage instrumentation code. If the answer is that a new tool probably needs to be written for that, I’d be happy to take a shot at it. If the answer is that it’s not possible to get such a descriptive source-level CFG from the coverage tool then I’ll be a sad panda.