Generating Define-Use Paths for C Code coverage analysis -

how possible generate uncovered define-use paths c code (using e.g. gcc). saw subject academic. (unlike line coverage)

resource: http://whiteboxtest.com/data-flow-testing.php

you need tool can determine every definition, possible uses (e.g., computes def-use pairs) in code, associate each def-use pair variable defined , program location (file, line, column) of def , use points.

then each def-use pair, need add instrumentation ("probes") program records use of def-use pair, when gets used (usually near use), kind of boolean variable specific def-use pair. because there lot of these useful organize individual booleans boolean array. (obvious optimization minimize number inserted probes: basic block, when executed, satisfy many def-use pairs; boolean representing execution of basic block [block coverage] can stand in set of def-use pairs. i'm sure there other similar optimizations.).

after running program, 1 has dump these boolean variables, compute actual def-use information (e.g., including using block coverage data), , display it.

a standard scheme modifying program source-to-source program transformations. paper branch coverage arbitrary languages made easy shows how our dms software reengineering toolkit , style of rewrite rules. paper focuses on branch (block) coverage, instrumentation aspect fine. typical transformation rule used looks this:

rule mark_if_then_else(condition:expression; tstmt:statement; estmt:statement)=    “if (\condition) \tstmt else \estmt;” rewrites    “if (\condition)        { visited[\new_place\(\tstmt\)]=1;          \tstmt}     else        { visited[\new_place\(\estmt\)]=1;          \estmt        };”  

this rule modifies , if-then-else construct collect "visited" booleans each conditionally executed block (then , else clauses) generating new index each new block. \xxxx means "an arbitrary code structure of syntax type ssss if transformation rule signature (first line) declares ssss:xxxx. can see more information on precise syntax , meaning of dms rewrite rules here.

it turns out getting def-use information hard; need amounts compiler front end op's mention of gcc. gcc won't source-to-source transformations can same effect source-to-binary transformations gcov does, modifying gcc sources procedural code add probes. in general, though, gcc doesn't want kind of custom instrumentation.

i don't know, i'm pretty sure clang computes def-use information. possible source source transformations clang have no experience that.

i know our dms compute def-use information c , c++. , ability source-to-source transformations make building def-use coverage tool technically straightforward. (not asked, dms computes control flows, 1 path coverage straightforwardly.)

then there problem of building display tool. need can show def use pairs , status, associated with/superimposed on the code easy understand each def , use. need record line , column-precise information location of each def , use. don't think can gcc; doesn't have information in binary, maybe has in constructed ast. can column information dms , clang (i think).