capstone/HACK.TXT
R3v0LT 9daa1ffbac
Add HPPA(PA-RISC) architecture (#2265)
* Refactor HPPA

* Add full HPPA 1.1 instructions support

* Add HPPA 1.1 cs tests

* Fix HPPA dissassembler

* Add HPPA 2.0 instructions

* Add HPPA tests

* Fix HPPA disasm & printer

* Update HPPA tests

* Remove unused code

* Add implicit register access info & Refactor HPPA main files

* Add python bindings/tests and cstests

* Fix HPPA disasm wrong decoding

* Rewrite invalid test cases

* Update HPPA python constants

* Make HPPA python test executable

* Change HPPA python tests sequence to match c tests

* Refactor HPPA main files

* Write target instead of offset in details

* Add HPPA detail function support in cstest

* Rewrite targets in branch tests

* Make correct string modifier addition

* Add hppa test calls

* Add zero operands check

* Remove MCOperand array

* Change immediate values printing

* Add HPPA 2.0 wide support

* Fix invalid break instruction decode

Remove unused code

* Add HPPA to fuzzing tests

* Add HPPA to options

* Add HPPA to docs

* Refactor HPPA

* Fix invalid branch insn decoding

* Add HPPA to labeler

* clang-format hppa files

* Document internal structures and minor refactoring

* Add missing default statements

* Fix invalid default statement
2024-03-26 13:58:56 +08:00

136 lines
5.1 KiB
Plaintext

Code structure
--------------
Capstone source is organized as followings.
. <- core engine + README + COMPILE.TXT etc
├── arch <- code handling disasm engine for each arch
│   ├── AArch64 <- AArch64 engine
│   ├── Alpha <- Alpha engine
│   ├── ARM <- ARM engine
│   ├── BPF <- Berkeley Packet Filter engine
│   ├── EVM <- Ethereum engine
│   ├── HPPA <- HPPA engine
│   ├── M680X <- M680X engine
│   ├── M68K <- M68K engine
│   ├── Mips <- Mips engine
│   ├── MOS65XX <- MOS65XX engine
│   ├── PowerPC <- PowerPC engine
│   ├── RISCV <- RISCV engine
│   ├── SH <- SH engine
│   ├── Sparc <- Sparc engine
│   ├── SystemZ <- SystemZ engine
│   ├── TMS320C64x <- TMS320C64x engine
│   ├── TriCore <- TriCore engine
│   └── WASM <- WASM engine
├── bindings <- all bindings are under this dir
│   ├── java <- Java bindings + test code
│   ├── ocaml <- Ocaml bindings + test code
│   └── python <- Python bindings + test code
├── contrib <- Code contributed by community to help Capstone integration
├── cstool <- Cstool
├── docs <- Documentation
├── include <- API headers in C language (*.h)
├── msvc <- Microsoft Visual Studio support (for Windows compile)
├── packages <- Packages for Linux/OSX/BSD.
├── windows <- Windows support (for Windows kernel driver compile)
├── suite <- Development test tools - for Capstone developers only
├── tests <- Test code (in C language)
└── xcode <- Xcode support (for MacOSX compile)
Follow the instructions in COMPILE.TXT for how to compile and run test code.
Note: if you find some strange bugs, it is recommended to firstly clean
the code and try to recompile/reinstall again. This can be done with:
$ ./make.sh
$ sudo ./make.sh install
Then test Capstone with cstool, for example:
$ cstool x32 "90 91"
At the same time, for Java/Ocaml/Python bindings, be sure to always use
the bindings coming with the core to avoid potential incompatibility issue
with older versions.
See bindings/<language>/README for detail instructions on how to compile &
install the bindings.
Coding style
------------
- C code follows Linux kernel coding style, using tabs for indentation.
- Python code uses 4 spaces for indentation.
Updating an Architecture
------------------------
The update tool for Capstone is called `auto-sync` and can be found in `suite/auto-sync`.
Not all architectures are supported yet.
Run `suite/auto-sync/Updater/ASUpdater.py -h` to get a list of currently supported architectures.
The documentation how to update with `auto-sync` or refactor an architecture module
can be found in [docs/AutoSync.md](docs/AutoSync.md).
If a module does not support `auto-sync` yet, it is highly recommended to refactor it
instead of attempting to update it manually.
Refactoring will take less time and updates it during the procedure.
The one exception is `x86`. In LLVM we use several emitter backends to generate C code.
One of those LLVM backends (the `DecoderEmitter`) has two versions.
One for `x86` and another for all the other architectures.
Until now it was not worth it to refactoring this unique `x86` backend. So `x86` is not
supported currently.
Adding an architecture
----------------------
If your architecture is supported in LLVM or one of its forks, you can use `auto-sync` to
add the new module.
<!-- TODO: Move this info to the auto-sync docs -->
Obviously, you first need to write all the logic and put it in a new directory arch/newarch
Then, you have to modify other files.
(You can look for one architecture such as EVM in these files to get what you need to do)
Integrate:
- cs.c
- cstool/cstool.c
- cstool/cstool_newarch.c: print the architecture specific details
- include/capstone/capstone.h
- include/capstone/newarch.h: create this file to export all specifics about the new architecture
Compile:
- CMakeLists.txt
- Makefile
- config.mk
Tests:
- tests/Makefile
- tests/test_basic.c
- tests/test_detail.c
- tests/test_iter.c
- tests/test_newarch.c
- suite/fuzz/platform.c: add the architecture and its modes to the list of fuzzed platforms
- suite/capstone_get_setup.c
- suite/MC/newarch/mode.mc: samples
- suite/test_corpus.py: correspondence between architecture and mode as text and architecture number for fuzzing
Bindings:
- bindings/Makefile
- bindings/const_generator.py: add the header file and the architecture
- bindings/python/Makefile
- bindings/python/capstone/__init__.py
- bindings/python/capstone/newarch.py: define the python structures
- bindings/python/capstone/newarch_const.py: generate this file
- bindings/python/test_newarch.py: create a basic decoding test
- bindings/python/test_all.py
Docs:
- README.md
- HACK.txt
- CREDITS.txt: add your name