device.init purego dlopen SIGSEGV on darwin crashes any importing test binary (Go 1.26.2, ztensor v1.19.0)

[dndungu]

Found during zerfoo Phase 0 work (zerfoo T129.1, PR zerfoo#916): on a darwin dev host with Go 1.26.2 and ztensor v1.19.0, ANY test binary that imports the compute/device path crashes at process startup inside device.init (purego dlopen SIGSEGV) — before any test runs, so even tests that would Skip on non-GPU hosts cannot run.

Reproduces on zerfoo main with pre-existing tests (tests/training bf16/gemma3 suites) and with the new fixture file removed — pre-existing and framework-wide on darwin, NOT introduced by the new test.

On Linux CI the same path is clean: device.init returns, NewGPUEngine errors gracefully, tests Skip as designed.

Impact: darwin developers cannot run any test package that transitively imports ztensor device init; zerfoo's tests/training is fully broken on mac hosts.

Suggested angle: guard the darwin dlopen probe (missing library should yield a clean 'no GPU' error, not a SIGSEGV in init).

Severity: dev-experience (no production impact); worth fixing before Phase 2 external contributors hit it on macs.

[dndungu]

Fixed and verified on the affected host (darwin/amd64, Go 1.26.2).

Root cause (confirmed empirically): the darwin dlopen shim handed syscall.syscall6 a func-value PC from funcPC(libc_dlopen_trampoline) (a func()-value double-dereference). On darwin/amd64 that resolves to the compiler-generated ABIInternal wrapper, not the raw ABI0 JMP trampoline. Measured on this host: funcPC(...) = 0x…de0 vs the true trampoline 0x…da0 (64 bytes off). syscall.syscall6 then CALLs that wrong PC as a C trampoline and control lands on a non-executable address → SIGSEGV during package init. (The linux/arm64 file had already abandoned this trampoline+funcPC mechanism for the same reason; darwin still used it.)

Fix (ztensor PR #172, released v1.19.1): adopt the golang.org/x/sys/unix darwin idiom — make each trampoline a file-local (<>) symbol and export its true ABI0 address to Go via an assembly DATA directive, then pass that address to syscall.syscall6. Contract-level (any darwin host without CUDA), amd64 + arm64, zero CGo preserved.

Observed verification (darwin/amd64):

Before — go test ./tests/training/ -run TestCaptureReplayGradientDivergence878:

SIGSEGV: segmentation violation
...dlopenImpl -> syscall.syscall6 -> device.init.0 (cuda_device.go:38)

After (ztensor v1.19.1 + the same fix ported to zerfoo's own internal/cuda copy, zerfoo PR #927):

--- SKIP: TestCaptureReplayGradientDivergence878 (0.00s)
ok  	github.com/zerfoo/zerfoo/tests/training

Full go test ./... on zerfoo: 126 packages ok, zero SIGSEGV (internal/cuda, internal/gpuapi, tests/training all green). The only remaining failure is a pre-existing flaky timing test (inference.TestGenerateBatch_ConcurrentSessions, "peak concurrent sessions") that passes in isolation — unrelated to this fix.

Note: zerfoo carries its own copy of the purego CUDA bindings with the identical darwin bug; the ztensor bump alone did not fix darwin — zerfoo's copy needed the same fix (zerfoo PR #927). Separately, with the probe fixed, ztensor's internal/metal dispatch now reaches a genuine Metal call that faults on darwin/amd64 (pre-existing, was masked by this crash) — tracked in #173.