Open bmourad01 opened 2 years ago
On second thought, maybe it's an issue with the Bil_to_bir
implementation:
https://github.com/draperlaboratory/cbat_tools/blob/119528b8f3465e2fff04658af27dff876263aad5/wp/lib/bap_wp/src/bil_to_bir.ml#L53
It seems to insert the goto %0000000f
in the block 00000008
even though 0000000f
is not reachable from this block.
Perhaps a fix would be to just run a pass on the generated blocks and remove all jump terms that occur after an unconditional jump within a given block.
Yes, indirect jumps are treated as a "goto exit" currently. I built in a handler for them (here: https://github.com/draperlaboratory/cbat_tools/blob/119528b8f3465e2fff04658af27dff876263aad5/wp/lib/bap_wp/src/precondition.ml#L419), but I'm not sure what the best way to populate it is.
Consider the following BIL program:
We would expect that the final value of
#56
will be conditional, summarized by the postcondition:However, this is not how WP treats it in BIR:
And indeed, it seems to treat the
goto #56
at tid0000000c
as a no-op, which results in our goal above being refuted.A solution would be to tighten assumptions about the behavior of indirect jumps (perhaps here?)