* Added encoding field to instructions, as per encoding branch
The encoding branch appears to have added some useful fields
accessible from the public API, including the size and offsets
of displacements and immediates in instructions. I needed access
to these fields, but the encoding branch is months behind the
active branches, so I took the minimum code from the old encoding
branch and put them into a more recent version of master.
It does seem that the most recent version does not have an offset
for the modRM byte in the InternalInstruction struct, so I did
not keep this field when bringing it to the more recent version.
I also added some of the changes made by user jellever, who added
support for accessing these new fields from the python bindings.
(cherry picked from commit d358c4b987cc77af90e24da15937e021c42f682f)
* Fixed bug with python bindings from adding encoding field
I had forgotten an import that resulted in failure when trying
to obtain instruction details.
(cherry picked from commit 44a15e378900efb624e7cdb952d32558ba0de684)
* promoted displacement to 64 bits
* Added modrm offset
* formatting from review fixed
* updated 32 bit C tests
* Added 64 and 16 bit C tests
* Updated python tests
* fixed formatting and size in py bindings
* Delete Solution.VC.db-shm
* Delete Solution.VC.db-wal
* Update test_x86.c
* fixed formatting and conditional prints
* fixed formatting
* Rename test.c to test_basic.c with corresponding executable name change.
* Fix Makefile, tests/Makefile to comprehend renamed test program. See issue #922
* Fix XCode project to comprehend renamed test program. See issue #922
* Rename python test.py to test_basic.py to parallel C test name. See issue #922
* Rename ocaml test.ml to test_basic.ml to parallel C test name. See issue #922
* Fix MSVC project definitions to comprehend renamed test program. See issue #922
When the python bindings are installed using the new wheels
infrastructure, data_files are relative to the site-packages directory
even if using absolute paths.
The following example demonstrates the bug fixed by this commit: (ran on archlinux)
```bash
$ pip install wheel # if this package is installed, wheel installation is made the default
Collecting wheel
Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% |################################| 71kB 124kB/s
Installing collected packages: wheel
Successfully installed wheel-0.29.0
$ pip install capstone # this will use the wheel installation method now
Collecting capstone
Using cached capstone-3.0.4.tar.gz
Building wheels for collected packages: capstone
Running setup.py bdist_wheel for capstone ... done
Stored in directory: /root/.cache/pip/wheels/7c/d1/d0/db6e2c5ef1063aabb9de2dd8b92b4c27ee6f9fd213240099b8
Successfully built capstone
Installing collected packages: capstone
Successfully installed capstone-3.0.4
$ find /usr/lib/ -name "libcapstone.so"
/usr/lib/python3.5/site-packages/usr/lib/python3.5/site-packages/capstone/libcapstone.so
```
So the path `SITE_PACKAGES` in the `data_files` specification of the
setup.py file was interpreted relative to the python site-packages
directory. The fix for this is simple: use `/capstone` instead of an
absolute path for `SITE_PACKAGES`.
El Capitan does not guaranteed that
(DY)LD_LIBRARY_PATH will exist, so force
one last check for the default install
directory that the install script uses.
In a virtualenv:
- site.getusersitepackages() won't import
- get_python_lib() will return the directory inside the virtualenv
- the "--user" option can therefore be safely ignored.
These changes will allow a pypi user to locally install capstone using the --user flag. If it possible, please update the correspondent package (https://pypi.python.org/pypi/capstone/3.0.3)
