Support macOS ARM64

[ligurio]

Original changes in the PR #58

Closes #59
Related to #67

[ligurio]

@seclorum @mzfr This patch series adds support for macOS ARM64, and after code review the patches will be added to the main branch. I would appreciate any feedback and testing.

[mzfr]

Hi @ligurio Thanks for taking over this.

I just tested on macOS ARM64 (M4), Darwin 24.6.0

Toolchain: LLVM 22.1.1, LuaJIT 2.1.1772619647, cmake 4.3.0 (all from homebrew)

used:

cmake -DCMAKE_C_COMPILER=/opt/homebrew/opt/llvm/bin/clang \
     -DCMAKE_CXX_COMPILER=/opt/homebrew/opt/llvm/bin/clang++ \
     -DENABLE_LUAJIT=ON \
     -DLUA_INCLUDE_DIR=/opt/homebrew/Cellar/luajit/2.1.1772619647/include/luajit-2.1 \
     -DLUA_LIBRARIES=/opt/homebrew/Cellar/luajit/2.1.1772619647/lib/libluajit-5.1.dylib \
     -DCMAKE_BUILD_TYPE=Release -S . -B build
   cmake --build build --parallel

Everything worked cleanly

• All output files are correct ARM64 Mach-O dylibs
• All three examples run (basic, custom_mutator, ffi_zlib)
• Custom mutator example finds the crash as expected
• luzer.path.asan / luzer.path.ubsan point to valid .dylib files
• AppleClang now gives a clear rejection message instead of the old confusing SetClangRTLib.cmake error

So LGTM :)

[ligurio]

@mzfr many thanks for the feedback!

[Buristan]

Hi, Sergey!
Thanks for the patch set!
I'll proceed with the review per-patch below.

---

[PATCH 1/4] luzer/tests: refactoring

LGTM, after fixing one comment below.

[Buristan]

[PATCH 2/4] luzer: refactoring search_module_path()

LGTM, with two minor comments below.

[Buristan]

Let's print dlerror(); here in case when it is available.

[ligurio]

Updated:

--- a/luzer/luzer.c
+++ b/luzer/luzer.c
@@ -154,8 +154,10 @@ NO_SANITIZE const char *
 search_module_path(char *base_path) {
        Dl_info dlinfo;
        int rc = dladdr((void *)&get_coverage_symbols_location, &dlinfo);
-       if (!rc)
+       if (!rc) {
+               fprintf(stderr, "%s\n", dlerror());
                return NULL;
+       }
        char *path = realpath(dlinfo.dli_fname, base_path);
        if (!path) {
                perror("realpath");

[Buristan]

dlerror() may return NULL, but I suppose we OK with it.

[Buristan]

[PATCH 3/4] luzer: use CMAKE_SHARED_LIBRARY_SUFFIX

LGTM.

[Buristan]

[PATCH 4/4] luzer: add macOS ARM64 support

LGTM, in general with a few questions and comments below.

Some side notes below.
At first, I can't build luzer on macOS (I've using the same command as #77 (comment)):

/opt/homebrew/opt/llvm/bin/clang --version 
Homebrew clang version 21.1.5
Target: arm64-apple-darwin25.3.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/21.1.5/bin
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin25.cfg

ld: warning: '/Users/s.kaplun/review/luzer/master/build/luzer/libclang_rt.asan_abi_osx.a[arm64][2](asan_abi_shim.cpp.o)' has malformed LC_DYSYMTAB, expected 45 undefined symbols to start at index 151, found 42 undefined symbols starting at index 151
[ 78%] Built target build_dso_ubsan
[ 78%] Built target build_dso_asan
[ 85%] Linking CXX shared library luzer_impl.dylib
Undefined symbols for architecture arm64:
  "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
      std::__1::__hash_const_iterator<std::__1::__hash_node<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, void*>*> std::__1::__hash_table<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) const in libclang_rt.fuzzer_no_main_osx.a[arm64][3](FuzzerDataFlowTrace.cpp.o)

It looks like that this caused by using the default AppleClang libraries instead.

The following lines before build fixes this issue for me, but ld warning still persisted.

export LDFLAGS="-L/opt/homebrew/opt/llvm/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm/include"

I suppose it would be nice to add this to the CONTRIBUTING.md.

With this fixup I've got the following errors for all ASAN/UBSAN-related tests (Debug or Release build):

28: dyld[47500]: terminating because inserted dylib '/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' could not be loaded: tried: '/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file), '/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file)
28: dyld[47500]: tried: '/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file), '/opt/homebrew/Cellar/llvm/22.1.1/lib/clang/22/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file)
28/28 Test #28: luzer_ffi_ubsan_null_pointer_deref ..............Subprocess aborted***Exception:   0.00 sec

But all ld warnings and test failures was fixed by updated brew's llvm to the latest version (looks like this is due to hardcoded path in tests configuration).

[Buristan]

Why do you want to disable this?