Description
Feature
- New architecture module
- Support for processor extension
- Add more instruction details (elaborated below)
- Binding support for:
language - Other (elaborated below)
Describe the feature you'd like
There is a common problem that LLVM code shares decoder or printer function names. We always need to add a static in this case, otherwise the linking fails.
Also, by default all functions are exported. No matter where they are. The only limit of users of the library is the header file Capstone distributes.
We should make the LLVM code a self contained module, merrily depending on the MC-header files and header files of their respective arch module (for add_cs_detail()).
By default all symbols from LLVM and arch module code should be hidden (build with -fvisibility=hidden) and only export the functions defined in ARCHLinkage.h. Same for the the arch module code (ARCHMapping and the like).
This will greatly reduce linking issues, enforce better logical separation between CS and LLVM code and ease code generation (due to less patching needed).
What we should have is something like this:
+------+ exported: +-------------+ printInstr() +-------------+
| Core | <----- ARCHModule.c | arch module | add_cs_detail() <------> getInstruction() | LLVM module |
+------+ fcns +-------------+ +-------------+
Additional context
The disadvantage is possibly, that we add an artificial boundary between LLVM and Capstone arch module code. LLVM code needs to call into the ARCHMapping.c and ARCHMapping uses quite some LLVM enums and MCInst code to make decisions which details to add and the like.