capstone-rust / capstone-sys Goto Github PK

low-level Capstone system bindings for Rust

License: MIT License

Rust 1.22% CMake 0.07% C++ 1.01% C 89.48% Makefile 0.14% Python 1.57% Java 1.80% Shell 0.05% OCaml 1.04% PowerShell 0.07% Visual Basic 0.41% Batchfile 0.05% Tcl 0.01% Smalltalk 2.31% C# 0.75% CSS 0.02%

bindgen capstone rust

capstone-sys's People

Contributors

Stargazers

Watchers

Forkers

darfink tmfink felberj fchiba mthiesen guedou f0rki waywardmonkeys zhangzhuosjtu cbiffle mothran moneytech

capstone-sys's Issues

on Arch Linux can't find native capsone library

error: could not find native static library `capstone`, perhaps an -L flag is missing?

error: aborting due to previous error

error: Could not compile `capstone-sys`.

Installed capstone library community/capstone 3.0.5-1 [installed]

I had to yank 0.3

This is primarily my fault for not doing an in depth review, and not wanting to maintain this very much, but imho, the crate is:

a substantial downgrade from the previous version, 0.2
has multiple bugs

For example, here are some major issues after trying to use it briefly:

Using system binding balloons a fresh compile to 1-3 minutes - this is completely unacceptable for essentially the rust version of a simple C #include. For comparison, compiling a fresh capstone on fcc8eac using system bindings was 1/2-2 seconds...
None of the bindings are documented anymore!
Related to 1, using the bundled bindings should never ever pull down bindgen, etc., and unrelated crates
There's no reason to use lazy_static in the build.rs for a log file (the build isn't multithreaded); all this does is complicate the build and increase compile times. Furthermore, there's no reason to have a build log file at all, as this is all printed directly in the output file in the respective deps directory. Even worse, passing -vvv doesn't print anything anymore; this just breaks user expectations.
The feature flags aren't coherent - the lib.rs includes either the bundled or not-bundled depending on the feature flag, but use_system_capstone isn't reflected in this at all, nor is it depended on or dependent of the bundled flag
There are non-existent feature flags in the build.rs, "build_src_cmake" (from the previous iterations); this indicates to me it was never tested.
Bindgen dynamic output needs to be an optional feature flag; this should 100% not be the default

Those are some of the major, show-stopping issues that forced me to yank.

Besides this, I'm thinking that bundling capstone was a really bad move; this is old style C vendoring. There was nothing wrong with the git module before, it was easily updateable, and it didn't force even a system binding user to download a 30MB crate.

Furthermore, the argument that the user doesn't have an internet connection is:

ok, then they should get their sys-admin or themselves to compile and install libcapstone.so and use the system bindings, or
untenable; they just used cargo to either download this crate as a dep, or they got it from the internet somewhere. Furthermore, the 4 dependencies and their 20 transitive dependencies need to be downloaded and compiled, so this is still untenable.

I understand that git submodules are sometimes undesirable, but I think this is a specific usecase where they are perfect precisely for what they're intended; and we don't force a 30MB download to someone who wants a 30k rust header file equivalent.

This brings me to the second point: using bindgen. I'm not even convinced this is a motivating usecase for the capstone bindings. As far as I know, the capstone ABI has been pretty rock-solid; I can't remember the last time it was changed, and I suspect it won't change anytime soon. Using bindgen to generate bindings only makes sense for the architecture header files which would have been prohitively difficult to write by hand; but could have been bindgen'd and then checked in quite easily, and the problem would have been solved.

Again, I should have downloaded, analyzed, and "lived in" the new version for a bit before merging and transferring this crate, but here we are.

Please don't take this in the wrong way; the current situation is just as much my fault as anyones, not having performed due process before the merge - but I hope we can rectify the situation, because as it stands now, I simply can't release these bindings as they stand.

At the end of the day, my decision to yank essentially came down to my answer to these questions:

Would I be ok using this library and reading the documentation? - No
Would I fork or write my own because it doesn't let me do what I want? - Yes

0.2 fresh compile, compiles capstone from source, after downloading from internet:
    Finished dev [unoptimized + debuginfo] target(s) in 14.13 secs

0.3 fresh compile, compiles bundled capstone from source
    Finished dev [unoptimized + debuginfo] target(s) in 140.72 secs

Some automated bindgen tests fail

This happens because of rust-lang/rust-bindgen#1213

Possible solutions:

Disable tests
Conditionally disable tests on archs that fail them
Refactor tests into a separate file

Example on stable-i686-pc-windows-msvc:

$ cargo test
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target\debug\deps\capstone_sys-4b9bbef9612e834d.exe

running 53 tests
test bindgen_test_layout___va_list_tag ... FAILED
test bindgen_test_layout_arm64_op_mem ... ok
test bindgen_test_layout_arm_op_mem ... ok
test bindgen_test_layout_cs_arm ... ok
test bindgen_test_layout_cs_arm64 ... ok
test bindgen_test_layout_cs_arm64_op ... ok
test bindgen_test_layout_cs_arm64_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_arm64_op__bindgen_ty_2 ... ok
test bindgen_test_layout_cs_arm_op ... ok
test bindgen_test_layout_cs_arm_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_arm_op__bindgen_ty_2 ... ok
test bindgen_test_layout_cs_detail ... ok
test bindgen_test_layout_cs_detail__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_insn ... FAILED
test bindgen_test_layout_cs_mips ... ok
test bindgen_test_layout_cs_mips_op ... ok
test bindgen_test_layout_cs_mips_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_opt_mem ... FAILED
test bindgen_test_layout_cs_opt_skipdata ... FAILED
test bindgen_test_layout_cs_ppc ... ok
test bindgen_test_layout_cs_ppc_op ... ok
test bindgen_test_layout_cs_ppc_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_sparc ... ok
test bindgen_test_layout_cs_sparc_op ... ok
test bindgen_test_layout_cs_sparc_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_sysz ... ok
test bindgen_test_layout_cs_sysz_op ... ok
test bindgen_test_layout_cs_sysz_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_x86 ... ok
test bindgen_test_layout_cs_x86_op ... ok
test bindgen_test_layout_cs_x86_op__bindgen_ty_1 ... ok
test bindgen_test_layout_cs_xcore ... ok
test bindgen_test_layout_cs_xcore_op ... ok
test bindgen_test_layout_cs_xcore_op__bindgen_ty_1 ... ok
test bindgen_test_layout_mips_op_mem ... ok
test bindgen_test_layout_ppc_op_crx ... ok
test bindgen_test_layout_ppc_op_mem ... ok
test bindgen_test_layout_sparc_op_mem ... ok
test bindgen_test_layout_sysz_op_mem ... ok
test bindgen_test_layout_x86_op_mem ... ok
test bindgen_test_layout_xcore_op_mem ... ok
test test::test_arch_arm ... ok
test test::test_arch_arm64 ... ok
test test::test_arch_mips ... ok
test test::test_arch_ppc ... ok
test test::test_arch_sparc ... ok
test test::test_arch_sysz ... ok
test test::test_arch_x86 ... ok
test test::test_arch_xcore ... ok
test test::test_cs_support ... ok
test test::test_cs_version ... ok
test test::test_non_arch_types ... ok
test test::test_x86_disassembly ... ok

failures:

---- bindgen_test_layout___va_list_tag stdout ----
	thread 'bindgen_test_layout___va_list_tag' panicked at 'assertion failed: `(left == right)`
  left: `16`,
 right: `24`: Size of: __va_list_tag', target\debug\build\capstone-sys-346b4f8e4123ac85\out/capstone.rs:9016:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- bindgen_test_layout_cs_insn stdout ----
	thread 'bindgen_test_layout_cs_insn' panicked at 'assertion failed: `(left == right)`
  left: `232`,
 right: `240`: Size of: cs_insn', target\debug\build\capstone-sys-346b4f8e4123ac85\out/capstone.rs:8602:4

---- bindgen_test_layout_cs_opt_mem stdout ----
	thread 'bindgen_test_layout_cs_opt_mem' panicked at 'assertion failed: `(left == right)`
  left: `20`,
 right: `40`: Size of: cs_opt_mem', target\debug\build\capstone-sys-346b4f8e4123ac85\out/capstone.rs:100:4

---- bindgen_test_layout_cs_opt_skipdata stdout ----
	thread 'bindgen_test_layout_cs_opt_skipdata' panicked at 'assertion failed: `(left == right)`
  left: `12`,
 right: `24`: Size of: cs_opt_skipdata', target\debug\build\capstone-sys-346b4f8e4123ac85\out/capstone.rs:189:4


failures:
    bindgen_test_layout___va_list_tag
    bindgen_test_layout_cs_insn
    bindgen_test_layout_cs_opt_mem
    bindgen_test_layout_cs_opt_skipdata

test result: FAILED. 49 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--lib'

This was reported by @mthiesen in #17

Add compatibility matrix

State in a table:

CPU
OS
Whether there are automated tests

Support FreeBSD

We should:

Test on FreeBSD
Set up CI tests

We could set up CI tests could be done with:

FreeBSD on Docker on Travis CI
FreeBSD on QEMU on Travis CI

Build failing on Ubuntu

When trying to compile on Ubuntu, I get the following error:

aron@aron-HP-ZBook-15-G2:/media/aron/HGST1/capstone-sys$ cargo +stable build -v
   Compiling capstone-sys v0.7.0 (file:///media/aron/HGST1/capstone-sys)
     Running `/media/aron/HGST1/capstone-sys/target/debug/build/capstone-sys-d3a190eb4b948c1e/build-script-build`
error: failed to run custom build command for `capstone-sys v0.7.0 (file:///media/aron/HGST1/capstone-sys)`
could not execute process `/media/aron/HGST1/capstone-sys/target/debug/build/capstone-sys-d3a190eb4b948c1e/build-script-build` (never executed)

System details:

aron@aron-HP-ZBook-15-G2:/media/aron/HGST1/capstone-sys$ uname -a
Linux aron-HP-ZBook-15-G2 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Is there any clue how to fix this?

Moving to Capstone 4.0?

There's going to be a new 4.0 release of Capstone soon-ish and there are already release candidates being made for it. This adds a bunch of new architectures and some new features.

Is there interest in moving this crate to one of the release candidates or should we wait for the official 4.0 release?

Upstream, I've started converting their doc comments to the format that bindgen picks up, so that the bindgen stuff can draw more directly from the official Capstone doc comments if that's useful. Unfortunately, this turns up that there are at least 2 bugs in how bindgen processes doc comments that I plan to fix.

Support Windows

Windows support is untested/unsupported. We should fix that.

We can use App Veyor for Windows CI:
https://www.appveyor.com/

Build fails on Mac OS

Build fails on Mac OS. Looks like it's related to universal binaries.

$ uname -a
Darwin MBP-9.lan 15.6.0 Darwin Kernel Version 15.6.0: Sun Jun  4 21:43:07 PDT 2017; root:xnu-3248.70.3~1/RELEASE_X86_64 x86_64

$ cargo test --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling capstone-sys v0.5.0 (file:///private/tmp/capstone-sys)
     Running `rustc --crate-name build_script_build build.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=91fd7061497ec3b8 -C extra-filename=-91fd7061497ec3b8 --out-dir /private/tmp/capstone-sys/target/debug/build/capstone-sys-91fd7061497ec3b8 -L dependency=/private/tmp/capstone-sys/target/debug/deps`
     Running `/private/tmp/capstone-sys/target/debug/build/capstone-sys-91fd7061497ec3b8/build-script-build`
     Running `rustc --crate-name capstone_sys src/lib.rs --emit=dep-info,link -C debuginfo=2 --test --cfg 'feature="default"' -C metadata=7676b8490752beab -C extra-filename=-7676b8490752beab --out-dir /private/tmp/capstone-sys/target/debug/deps -L dependency=/private/tmp/capstone-sys/target/debug/deps -L native=/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out -l static=capstone`
     Running `rustc --crate-name capstone_sys src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=9227deac633b4afb -C extra-filename=-9227deac633b4afb --out-dir /private/tmp/capstone-sys/target/debug/deps -L dependency=/private/tmp/capstone-sys/target/debug/deps -L native=/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out -l static=capstone`
error: failed to add native library /private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out/libcapstone.a: failed to open archive

error: Could not compile `capstone-sys`.

Caused by:
  process didn't exit successfully: `rustc --crate-name capstone_sys src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg feature="default" -C metadata=9227deac633b4afb -C extra-filename=-9227deac633b4afb --out-dir /private/tmp/capstone-sys/target/debug/deps -L dependency=/private/tmp/capstone-sys/target/debug/deps -L native=/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out -l static=capstone` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed

$ file /private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out/libcapstone.a
/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out/libcapstone.a: Mach-O universal binary with 2 architectures
/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out/libcapstone.a (for architecture i386):   current ar archive random library
/private/tmp/capstone-sys/target/debug/build/capstone-sys-e0d35610293786b0/out/libcapstone.a (for architecture x86_64): current ar archive random librar

Support next branch of Capstone?

I am not sure whether this is necessary. But from my case, I am trying to get access info of registers. As this post indicates, capstone in next branch has support cs_regs_access() which is much more useful than reg_read and reg_write.

Thus, what I did are as follows:

use update_capstone.sh to update capstone into the next branch.
Because in the new version of capstone, header files are moved into include/capstone (Actually, the newest commit of capstone's master branch has did that too), I edit build.rs like:

header_search_paths.push([CAPSTONE_DIR, "include", "capstone"].iter().collect());

cargo build --features use_bindgen --all

However, after that, I gather following warning.

... <similar warning>...
warning: capstone/arch/X86/X86Mapping.c:2811:31: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_ADD_FrST0, X86_REG_ST0 },
warning:                                      ^
warning: capstone/arch/X86/X86Mapping.c:2812:31: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_SUB_FrST0, X86_REG_ST0 },
warning:                                      ^
warning: capstone/arch/X86/X86Mapping.c:2813:32: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_SUBR_FrST0, X86_REG_ST0 },
warning:                                       ^
warning: capstone/arch/X86/X86Mapping.c:2814:31: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_MUL_FrST0, X86_REG_ST0 },
warning:                                      ^
warning: capstone/arch/X86/X86Mapping.c:2815:31: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_DIV_FrST0, X86_REG_ST0 },
warning:                                      ^
warning: capstone/arch/X86/X86Mapping.c:2816:32: warning: missing field 'access' initializer [-Wmissing-field-initializers]
warning:         { X86_DIVR_FrST0, X86_REG_ST0 },
warning:                                       ^
warning: 102 warnings generated.
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(M68KModule.o) has
no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(M680XModule.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(M680XInstPrinter.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(M680XDisassembler.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(TMS320C64xInstPrinter.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(TMS320C64xDisassembler.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(TMS320C64xModule.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(TMS320C64xMapping.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(EVMModule.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /private/tmp/capstone-sys/target/debug/build/capstone-sys-70045b853a024ad6/out/libcapstone.a(EVMMapping.o) has
no symbols
    Finished dev [unoptimized + debuginfo] target(s) in 0.97s

I thought it was caused by the wrong way of compiling capstone. But I am not so familiar with capstone's source files. So that I am wondering whether anyone could help me. I will also work on this but it might cause more time.

Thanks a lot.

Improve CI tests

We currently only test the default features; we should test different combinations of features.
We should test that the pre-generated capstone bindings match the ones dynamically generated with bindgen.

Automate documentation

Bindgen no longer generates documentation for elements. However, Rust doc comments are more friendly than reading the C capstone headers.

We should add a script (or Rust code) that can add documentation to the pre-generated bindings.