v23.5.0 SIGSEGV on macOS arm64 when processing standard VAMS includes

[bryancostanich]

Summary

openvaf (built from current main, reports v23.5.0) reliably SIGSEGVs on macOS arm64 the moment it tries to compile any .va that contains `include "disciplines.vams" or `include "constants.vams". Reproduces on a trivial 8-line resistor. Crash is in the bundled-header loading path — providing the headers via -I doesn't help. Compilation of .va files that don't use the standard includes works (parses, gives clean diagnostic errors), so the binary itself loads fine; the crash is specifically in the include-resolution code path.

Environment

• macOS 26.2, Apple Silicon (arm64)
• OpenVAF: built from main (clones report v23.5.0)
• LLVM: llvm@15 15.0.7 from Homebrew (LLVM 17+ removed PassManagerBuilder.h that the wrapper still depends on)
• Rust: stable, recent
• ngspice 46 (separately installed; not yet exercised since openvaf can't produce a .osdi)

Build patches I applied to get openvaf to compile at all

Surfacing in case any of these are relevant to the runtime crash:

1. openvaf/target/build.rs — skip Windows UCRT importlib generation on non-Windows hosts. Stock build.rs unconditionally calls clang-cl to build ucrt_x64.lib / ucrt_arm64.lib, which fails on macOS where clang-cl doesn't exist. Patch:

   // before:
   let check = tracked_env_var_os("RUST_CHECK").is_some();
   gen_msvcrt_importlib(&sh, "x64", "x86_64", check);
   gen_msvcrt_importlib(&sh, "arm64", "aarch64", check);
   
   // after:
   let check = tracked_env_var_os("RUST_CHECK").is_some();
   let host_os = std::env::var("CARGO_CFG_TARGET_OS").unwrap_or_default();
   let force_check = check || host_os != "windows";
   gen_msvcrt_importlib(&sh, "x64", "x86_64", force_check);
   gen_msvcrt_importlib(&sh, "arm64", "aarch64", force_check);

2. LLVM_CONFIG=/opt/homebrew/opt/llvm@15/bin/llvm-config — needed because the C++ wrapper still includes llvm/Transforms/IPO/PassManagerBuilder.h, which was removed from LLVM in 17+.

3. LIBRARY_PATH=/opt/homebrew/opt/zstd/lib:… — without this the final link fails with ld64.lld: error: library not found for -lzstd.

4. --target aarch64-apple-darwin passed explicitly to the resulting binary — the default target detection on macOS arm64 emits the invalid string aarch64-apple (no -darwin suffix), which is then rejected by openvaf's own arg parser.

Reproduction

Trivial .va file:

`include "constants.vams"
`include "disciplines.vams"

module trivial_resistor(p, n);
    inout p, n;
    electrical p, n;
    parameter real R = 1.0e3 from (0:inf);
    analog begin
        I(p, n) <+ V(p, n) / R;
    end
endmodule

Run:

$ openvaf --target aarch64-apple-darwin trivial.va
$ echo "exit=$?"
exit=139

Same SIGSEGV with:

• --target x86_64-apple-darwin
• --dry-run
• -b (batchmode)
• -O 0, -O 3
• -I /opt/homebrew/Cellar/icarus-verilog/13.0/lib/ivl/include (where icarus's bundled VAMS headers live)
• A copy of disciplines.vams and constants.vams placed alongside the .va with -I .

What does not crash

A .va file that doesn't use the standard includes parses cleanly and produces proper diagnostics:

module simple(a, b);
    inout a, b;
    electrical a, b;       // <- no include for disciplines.vams
    parameter real R = 1.0e3;
    analog begin
        I(a, b) <+ V(a, b) / R;
    end
endmodule

$ openvaf --target aarch64-apple-darwin no_inc.va
error: 'electrical' was not found in the current scope
  --> /tmp/no_inc.va:3:5
…
exit=65

So the binary loads, the arg parser works, the parser/sema works on plain syntax. The crash is specifically in whatever code path handles the `include "disciplines.vams" / `include "constants.vams" directive.

strings $(which openvaf) | grep vams confirms openvaf bundles the standard VAMS header content internally. The crash is presumably in the bundled-header lookup or substitution code on macOS arm64.

Impact for our use case

Blocking real .va compilation for the sky130_fd_pr_reram__reram_cell.va model (SkyWater RRAM, ships in the public sky130_fd_pr_reram repo), which uses the standard includes. We've ended up landing the surrounding ngspice .lib wrappers + smoke-test orchestrator on the assumption the bug will get a fix or we'll patch a fork; happy to share more diagnostics or test patches.

Asks

• Is this a known macOS arm64 issue?
• Anything I can grab from lldb / dtruss that would help triage?
• Is there a workaround flag / env var to bypass the bundled-header path entirely?

[Kreijstal]

use arpads version https://github.com/arpadbuermen/OpenVAF