Add control flow related information to JSON config #646
Comments
PeterMatula
added a commit
that referenced
this issue
Dec 17, 2019
* bin2llvmir/config: allow to set config as an existing object. * add retdec library and retdectool executable * bin2llvmir/global: remove unused passes and related analyses These make refactorization more difficult. If needed in the future, just search for them in GIT history. * bin2llvmirtool: remove unused command line options * Create a new library named common containing addresses and ranges This library will contain all the object common to several RetDec components. * common/address: remove dangerous AddressRange ctor * common/address: use Range to get AddressRange. * common: unify AddressRangeContainer with common RangeContainer. * create new serialization/deserialization library * progress * config: remove AddressRangeJson * config: move container (de)serialization methods to serdes lib * config: remove Segments representation It was not really used. * config: move architecture module to common * config: move FileFormat module to common * config: move FileType to common. * common: add basic block representation * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * progress * fix function fill * fix decoder * fix compilation * fix includes * rtti-finder: use vtable representation from the common library * fix * CHANGELOG.md: fix #686, fix #646, add entries for them. * serdes/std.h: fix std data types (de)serialization. * tests/common/address_tests: state AddressRange type for inserts and removes. This prevents some compilation errors on some macOS environments. * tests/common/address_tests: state AddressRange type for inserts and removes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Make it possible to store control flow information (i.e. basic blocks and their relations) in JSON config.
This could be used to pass this info from 3rd party tools (e.g. IDA, r2) to RetDec.
Also, if RetDec would produce such information, other 3rd party tools might consume it. Or we could use it to test the decoding phase in regression tests.
Related to:
radareorg/r2retdec#2
avast/retdec-idaplugin#7
The text was updated successfully, but these errors were encountered: