Repository navigation
build on macos arm64 support - #256
Conversation
- Add ARCH_AARCH64 detection in platform headers (wtf and kdmp-parser) - Build BLAKE3 as a static library with NEON support on arm64 - Rename blake3_compress_in_place_portable to avoid duplicate symbols with libbochscpu_ffi.a on arm64 - Use HAS_KVM guard instead of LINUX for KVM backend (macOS has no KVM) - Skip linking -ldl on Apple platforms - Enable __builtin_bswap on Apple in libfuzzer - Use __builtin_debugtrap() instead of int3 on aarch64 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LINUX was defined on macOS which is semantically wrong and a trap for future contributors. Rename it to POSIX since it guards non-Windows behavior shared by Linux and macOS. Also add FreeBSD #error guard back and separate OSX_* sub-macros from LINUX_* in wtf/platform.h to match kdmp-parser/platform.h. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Apply a patch to bochscpu/build.rs after cloning to add macOS filename entries and fix the tempfile cfg guard. Use a case statement for cargo build to keep --target on Linux and error on unsupported platforms. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move the GitHub API call and download inside the ./lib existence check in the bochscpu-macos.patch so the build script uses locally built libs on macOS instead of attempting to download releases from GitHub. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Build specific lib targets instead of relying on a blanket make that silently fails. Link libc++ on macOS and libstdc++ on Linux for the C++ bochs libraries. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rename library files to include the target architecture so Linux x86_64 and macOS arm64 builds can coexist without conflicts: - libbochscpu_ffi.a -> libbochscpu_ffi_x86_64.a, libbochscpu_ffi_arm64.a - bochscpu_ffi.lib -> bochscpu_ffi_AMD64.lib CMakeLists.txt now uses CMAKE_SYSTEM_PROCESSOR to select the right file. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Set CMAKE_OSX_DEPLOYMENT_TARGET and MACOSX_DEPLOYMENT_TARGET from sw_vers -productVersion so the wtf build and bochscpu build agree on the deployment target, eliminating linker version mismatch warnings. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace the flat if(WIN32)/elseif(arm64)/elseif(x86_64) with a proper OS-first structure: if(WIN32)/elseif(UNIX) with arch checks nested inside the UNIX branch. Unknown OS or arch now triggers FATAL_ERROR. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rename library files to include both OS and architecture to prevent conflicts between same-arch different-OS builds (e.g., arm64 macOS vs arm64 Linux): - libbochscpu_ffi_Darwin_arm64.a - libbochscpu_ffi_Linux_x86_64.a - bochscpu_ffi_Windows_AMD64.lib CMakeLists.txt uses CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR to select the right file. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- __builtin_debugtrap is Clang-only; use raise(SIGTRAP) on GCC aarch64 - Restrict HAS_KVM to x86_64 because the KVM backend uses x86-specific structures (kvm_lapic_state, kvm_regs, etc.) absent from arm64 KVM Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The --target x86_64-unknown-linux-gnu flag is only needed on x86_64 Linux due to a Rust toolchain issue. Other architectures use plain cargo build --release. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Flatten the if/else tree into independent blocks: OS checks (WIN32, UNIX, Linux), arch checks (arm64, x86_64), and combined only where genuinely needed (Unix x86_64 GAS assembly). Reject unsupported platforms and architectures early with FATAL_ERROR. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Amazing, thank you very much for this! Give me a week or two to get this reviewed :) Cheers |
|
I started to look at the changes and I noticed you modified some files in |
|
Thanks for taking a look at this! No, I only modified the files within this repo. I didn't know kdmp-parser was also a separate repo. I'l test if this works without any changes to that folder by backporting that commit. This is a bit outside the initial scope but maybe it would make sense to have kdmp-parser be a submodule? |
|
I've manually added the changes from the commit you referenced and it seems to work as well. I also considered updating the kdmp-parser version altogether (perhaps on a separate PR) but it seems that commit is not included in the latest release. |
bbda55f to
a8bee57
Compare
|
All right, I removed the Cheers |
|
Ok, last thing I want to take a look at is maybe try to untangle a little bit this Cheers |
|
All right; I think this looks good to me, I'd appreciate if you could take a look at my changes @ogalland-tob just in case I messed something up; if you don't have minute no worries, don't sweat it The last thing I want to figure out is.. what do I do with the OSX/arm64 library files; until now I was building lin/winx64 manually, but with lin/osxarm64 I might just start using artefacts directly off the bxcpu repository itself. Cheers |
|
Thanks for working on this! I'll take a look at and test the changes and get back to you. Regarding the binaries, the build scripts in this repo closely match the workflow from bochscpu-build, so it should be possible to reuse those. |
|
Changes look good to me, it's also working with the latest CI build of |
|
Awesome, thank you for taking a look 🙏🏼 Cheers |
|
I updated bxcpu-ffi to automatically produce bins, @ogalland-tob if you have time would you mind giving a test to the artifacts from this pipeline as neither Axel nor I have a mac. This basically just finishes plumbing through your earlier bxcpu-build and bxcpu work. https://github.com/yrp604/bochscpu-ffi/actions/runs/32215447881 |
|
@yrp604 I smoke-tested this by linking This is what I've been doing for previous tests as well, but feel free to let me know if there's any test in particular that you'd want me to run to ensure broader coverage. Thanks! |
|
Sweet, I'll swap the binaries with the ones built by the CI and we'll be ready to merge \o/ Thanks again @ogalland-tob & @yrp604. Cheers |
|
OK so @yrp604 & I went into the CI tranches yesterday and got those binaries to be properly built. I'm just going to add a small utility to download the latest version / rename & put them where they need to go & will call this done, finally \o/ |
|
Thanks again @ogalland-tob and apologies for the delay, took a while to get this in 😅 Cheers |
I've made some modifications to get wtf building on macos, this included:
This shouldn't change anything functionally, it's intended to be the bare minimum to get the project to build on Apple silicon so I could start playing with it (since I was adding aarch64 support, I also got it to build on arm64 linux).
I've tested this locally and could run a simple fuzzing campaign on a Windows vm snapshot. I've also ran the CI on a private fork of this repo and it is green.
Note that this PR includes pre-built static libraries of bochscpu under
./src/libs/bochscpu-bins/lib/, since that's how they're usually vendored in the code. You might want to rebuild those using the build scripts under./src/libs/bochscpu-bins/and the new bochscpu-build release so you don't have to trust binary code built by a third-party like myself.Let me know if any changes are needed!