This week I merged cs2.1 into r2, so we'll be shipping it by default in the 
next release and now we are going to perform lot of testing to ensure we are 
not introducing any regression by a bug in capstone or a missuse of it.

The first stage is ready for testing and our build farm raised few issues.

- some c99 code (patch send and merged)
- android mips builds failed (workarounded), looks like 'mips' is defined to 1 
somewhere which causes cs build fail. I had to CFLAGS=-Dmips=mips
- coverity scan passed reporting some issues in cs code

Actually we are taking capstone from latest github tarball and then applying 
the c99 patch. It just builds the .a archive. Also, i have noticed that the 
windows library archive file name is .dll.a, so i was not able to use the same 
makrfile for w32 and linux builds... Wondering if .dll.a is correct, so i just 
passed AR_EXT=a to the make arguments.

The second stage of the capstone integration consists in checking all the 
regression testsuite (about 800 tests) to verify that the output of the 
disassembler is correct in all the corner cases we found during r2 development.

The third stage consists in swapping all the capstone plugins as default and 
remove all the gnu plugins from the main repo.

The main reason to switch to capstone for us are:
- well maintained disassembler library
- no license issues with LGPL
- complete instruction introspection

We'll keep you informed about how the second and third stages are going, join 
the irc (#radare at freenode) for more information.

--pancake


_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org

Reply via email to