Re: [DynInst_API:] Incorrect recognized basic blocks

[Barton Miller <bart@xxxxxxxxxxx>]

Let me follow up on Bill's very complete and well phrased answer with a comment more general than just Dyninst:

No static analysis tool can do a perfect job of finding basic blocks. Just not possible.

And no dynamic tool can do a perfect job either, because there is no guarantee that all the code will be exercised in all the possible ways that it could execute.

--bart miller

On 10/1/2015 11:02 AM, Bill Williams wrote:

On 10/01/2015 08:51 AM, chenping wrote:

Hello, Dyninst developers

ÂÂÂÂ I am using Dyninst to statically instrument the binary. Our work heavily depends on the correctness of the basic block recognization. So I would like to guarantee/know if there is any basic block cannot be correctly recognized.

Any function that is marked "instrumentable" is one for which we have correct basic blocks (or in the worst case, overzealous block splitting as a result of conservative indirect control flow analysis. Any function marked "uninstrumentable" is one that has unresolved indirect control flow, and requires dynamic techniques if you want to ensure that instrumentation is both safe and comprehensive at the block level: insert a dynamicTargetExpr at the indirect branch, and follow the control flow targets that it reveals. It is also possible for us to create incorrect basic blocks in a binary that has been stripped if our gap parsing algorithm yields a false positive, but the blocks that creates will be consistent with the function entry point we've (incorrectly) chosen, and in practice the code is likely to realign quite quickly.

Aside from stripped code and indirect control flow, I am not aware of any other reason we could have incorrect basic block boundaries. There are certain code idioms (getPC thunks, for example) that we elide and merge, but that's a deliberate choice. Likewise, we elide PLT stubs by choice.

ÂÂÂÂÂÂDo you have any method to automatically find the incorrect basic blocks? Or from your experience, is there any scenario when Dyninst cannot recognize the basic blocks correctly? If the basic blocks cannot be correctly recognized, is there method can guarantee the instrumented program works at runtime?

Any instrumentation we insert should be inserted safely: in functions that do not have complete control flow graphs, instrumentation should be reached by traps (expensive, but safe). However, if your instrumentation depends on block entry/exit being paired correctly in order to function, you will probably want to restrict your instrumentation to functions that can be safely relocated.

ÂÂÂÂÂ I am very appreciated for your help. Thanks!~


Bests,
Ping

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api