Unable to build with latest `next` branch on darwin/aarch64

[galderz]

OpenJDK can be configured with capstone but latest next branch fails to build with it.

After updating the capstone arch to -DCAPSTONE_ARCH=CS_ARCH_AARCH64, I still see this issue:

/bin/rm -f /Users/galder/1/jdk/build/fast/support/hsdis/hsdis-capstone.o.log && /usr/bin/clang -MMD -MF /Users/galder/1/jdk/build/fast/support/hsdis/hsdis-capstone.d.tmp -I/Users/galder/1/jdk/build/fast/support/modules_include/java.base -I/Users/galder/1/jdk/build/fast/support/modules_include/java.base/darwin -I/Users/galder/1/jdk/src/java.base/share/native/libjava -I/Users/galder/1/jdk/src/java.base/unix/native/libjava -I/Users/galder/1/jdk/src/hotspot/share/include -I/Users/galder/1/jdk/src/hotspot/os/posix/include -DMAC_OS_X_VERSION_MIN_REQUIRED=110000 -mmacosx-version-min=11.00.00 -DLIBC=default -D_ALLBSD_SOURCE -D_DARWIN_UNLIMITED_SELECT -DMACOSX -DDEBUG -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wreorder -Wunused-function -Wundef -Wunused-value -Woverloaded-virtual -g -gdwarf-4 -gdwarf-aranges -std=c11 -arch arm64 -D_LITTLE_ENDIAN -DARCH='"aarch64"' -Daarch64 -D_LP64=1 -I/Users/galder/opt/capstone/include/capstone -DCAPSTONE_ARCH=CS_ARCH_AARCH64 -DCAPSTONE_MODE=CS_MODE_ARM -I/Users/galder/1/jdk/src/utils/hsdis/capstone -I/Users/galder/1/jdk/src/utils/hsdis -g -gdwarf-4 -gdwarf-aranges -Wno-unknown-warning-option -Wno-unused-parameter -Wno-unused -Wno-undef -Wno-format-nonliteral -Werror -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/System/Library/Frameworks -c -o /Users/galder/1/jdk/build/fast/support/hsdis/hsdis-capstone.o /Users/galder/1/jdk/src/utils/hsdis/capstone/hsdis-capstone.c -frandom-seed="hsdis-capstone.c"

In file included from /Users/galder/1/jdk/src/utils/hsdis/capstone/hsdis-capstone.c:55:
/Users/galder/opt/capstone/include/capstone/capstone.h:341:14: error: expected member name or ';' after declaration specifiers
                cs_aarch64 aarch64; ///< AARCH64 architecture (aka AArch64)
                ~~~~~~~~~~ ^
<command line>:9:17: note: expanded from macro 'aarch64'
#define aarch64 1
                ^
In file included from /Users/galder/1/jdk/src/utils/hsdis/capstone/hsdis-capstone.c:55:
/Users/galder/opt/capstone/include/capstone/capstone.h:341:13: error: expected ';' at end of declaration list
                cs_aarch64 aarch64; ///< AARCH64 architecture (aka AArch64)
                          ^
                          ;
2 errors generated.

Could this be a macro expansion issue?

Is there any stable branch/version for using capstone that will work on darwin/aarch64? I've tried the commit before ef89b18 and that fails with:

/bin/rm -f /Users/galder/1/jdk/build/fast/support/hsdis/BUILD_HSDIS_link.log && /usr/bin/clang -mmacosx-version-min=11.00.00 -arch arm64 -L/Users/galder/1/jdk/build/fast/support/modules_libs/java.base -L/Users/galder/1/jdk/build/fast/support/modules_libs/java.base/server -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -L/Users/galder/opt/capstone/lib -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -Wl,-install_name,@rpath/libhsdis.dylib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/System/Library/Frameworks -o /Users/galder/1/jdk/build/fast/support/hsdis/libhsdis.dylib /Users/galder/1/jdk/build/fast/support/hsdis/hsdis-capstone.o
...
ld: warning: search path '/Users/galder/opt/capstone/lib' not found

[Rot127]

The Java bindings are definitely out of date. You can try v5 or the v4 branch.
Of cause, if you want to invest the time into updating them, it would be very much welcome.

[galderz]

This wasn't about the Java bindings, but rather about OpenJDK's use of capstone to diassembled JIT'd code.

One thing that worries us about these latest changes is the move from CS_ARCH_ARM64 to CS_ARCH_AARCH64. This is a public API change that is not backwards compatible, isn't it? How are clients supposed to deal with 4.x, 5.x and any future versions that include this change?

[galderz]

The issue in the description has been solved and was caused by a -Daarch64 macro definition in the C flags passed in to compile the hsdis facade that uses capstone in OpenJDK. I've managed to undefine the macro before importing capstone.h.

[theRealAph]

Couldn't CS_ARCH_ARM64 have been kept for backwards compatibility?
I guess the real question is this: does Capstone yet have a stable API? If not, it's very hard for other projects to use Capstone, lovely though it is in many ways.

[Rot127]

@theRealAph I made a release document justifying the API change here: https://github.com/Rot127/capstone/blob/v6-release-guide/docs/cs_v6_release_guide.md

The macros are still open as pull request but should be merged soon. If you (or anyone else) wants more details please let me know.

@kabeor After the macros are merged, can we talk again about a (very early) pre-release so attention is channeled to this document?

[theRealAph]

@theRealAph I made a release document justifying the API change here: https://github.com/Rot127/capstone/blob/v6-release-guide/docs/cs_v6_release_guide.md

The macros are still open as pull request but should be merged soon. If you (or anyone else) wants more details please let me know.

Fair enough. As, I guess, Capstone is still stabilizing it makes sense to clean up this stuff now. I've been trying to get disassembly support into some OpenJDK builds, but unexpected changes like this are something of a bump in the road, that's all. @galderz has come up with a nice workaround.

[Rot127]

As, I guess, Capstone is still stabilizing it makes sense to clean up this stuff now. 

Yes, the stabilizing part is the whole reason we changed it. I know that it is really annoying (I refactored our code for Rizin). But if Capstone wants some kind of future it needs a working updater and consistency. For both it is better to change the name.

[saagarjha]

If you need to support the previous version of Capstone as well, you can use those macros (see below helper scripts). Also, your can exclude/include code by checking CS_NEXT_VERSION < 6.

This doesn't seem to be exported to the Python API. Can we do that, please?