Dynamic fact generator

[adrianherrera]

Hey @langston-barrett and the Galois team,

First, thanks for putting the effort into developing cclyzer++!

I've been working on a tool that augments cclyzer++-generated facts with dynamic analysis facts. This is achieved via an LLVM instrumentation pass that records the names of basic blocks (so they match with the static facts) and a run time that then writes these facts to CSV files. I tried to reuse as much of the cclyzer++ machinery as I could, but I ended up having to duplicate some code to bend it to my will :) For example, the csv_writer had to be opened in append mode so I could record multiple program executions (e.g., with different inputs) in the same fact file. I also added an extra predicates.inc to record edge coverage facts.

Is this something you would be interested in? E.g., to incorporate into the main cclyzer++ repo, or to refactor the current code to make it easier for folks like me to extend the FactGenerator/FactWriter machinery to build our own tools?

The code is currently in a private repo, but I'm happy to share if you're interested.

Thanks again!

[langston-barrett]

@adrianherrera That sounds awesome! Out of curiosity, can you say more about what you hope to do with the facts from the dynamic analysis?

In any case, this sounds like a feature that could be useful for a variety of reasons. I'd be happy to review PRs that help move in this direction. Happy to accept PRs that change how the FactGenerator works, or to do some refactoring myself if the needed changes are reasonably small.

[thinkmoore]

Wow! Awesome to hear you are building on it! As Langston said we are happy to incorporate changes that make it easier to build off of.

Also super curious to hear about what you are working on. :) Are you planning to use the dynamic facts to augment the points-to analysis or using the facts as input to a different analysis?

[adrianherrera]

Cool, thanks for the enthusiasm :)

I'm a fuzzing person, so I'm trying to combine static analysis with fuzzing data (i.e., test-case coverage) to try and get a better idea of where the fuzzer is getting stuck, what is reachable from a particular fuzzing driver, etc. Also, it's an excuse to learn about Datalog-based program analysis.

In any case, I'll start with some relatively small/straightforward PRs that would make my tooling easier to integrate. Then we can go from there.

Thanks again @langston-barrett and @thinkmoore!