Large arm64 macOS debug binaries fail to exec since the v0 mangling default

[ashi009]

Since the switch to v0 mangling by default (#151994), the dev build of our
workspace (~1100 crates, debug = "line-tables-only") is killed at exec on
arm64 macOS:

dyld[90104]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed

With the default -Csplit-debuginfo=unpacked, ld64's debug map puts an
N_FUN stab with the full mangled name of every function into the
executable. Legacy names stay near-constant length under generic nesting (the
hash absorbs the type), while v0 names grow with it — the map is now
3,173,815 functions averaging 475 bytes per name (max 1558), a 1.51 GB
LC_SYMTAB strtab in a 2.45 GB binary, and once the image passes ~2 GB the
process no longer fits between its load address and the dyld shared region.

The scaling is visible on a 25-line file — a closure inside a generic
function, instantiated at type-nesting depth 4 vs 16:

$ git clone https://github.com/ashi009/v0-debug-map-repro && cd v0-debug-map-repro
$ for tc in 1.96.0 1.97.0; do rustc +$tc -V; for d in d4 d16; do rustc +$tc -Cdebuginfo=line-tables-only repro_$d.rs -o repro_$d; printf "repro_%s: " $d; nm -ap repro_$d | awk '$5=="FUN" && /4work/ {s+=length($NF)} END {print s+0}'; done; done
rustc 1.96.0 (ac68faa20 2026-05-25)
repro_d4: 332
repro_d16: 336
rustc 1.97.0 (2d8144b78 2026-07-07)
repro_d4: 334
repro_d16: 846

-Csymbol-mangling-version=legacy would be the escape hatch, but it is gated
on -Zunstable-options, so there is no stable way back to a bootable debug
build. Could that gate be lifted, or over-long names be hashed in the
debug-map path the way MCP 934 (#148429) does for PDB?

[bjorn3]

and once the image passes ~2 GB the
process no longer fits between its load address and the dyld shared region.

Why does it matter what the physical size of the executable is? At least on ELF the private symbol table never gets mapped into memory and thus wouldn't take up any address space.

Could that gate be lifted

It is intended to be removed entirely in the future.

or over-long names be hashed in the
debug-map path the way MCP 934 (#148429) does for PDB?

Possibly. What would be the threshold for hashing though? Each individual symbol in your case is still at most 1.5kb as you say, which is a completely fine size for smaller programs.

[ashi009]

Why does it matter what the physical size of the executable is?

Because on Mach-O the symbol table (__LINKEDIT) is a mapped segment — unlike ELF, symtab bytes are address-space bytes. And on arm64 macOS specifically, the address space for the whole image is just 2 GB: executables load at 0x100000000 (the 4 GB __PAGEZERO is mandatory on arm64) and the kernel reserves the dyld shared region directly above, at SHARED_REGION_BASE_ARM64 = 0x180000000. This is arm64-only by construction — the same header puts the x86_64 reservation at 0x00007FF800000000, ~127 TB above the image base, so no realistic binary ever hits it there.

So: 2 GB budget for __TEXT+__DATA+__LINKEDIT minus ASLR slide, and 1.5 GB of v0 N_FUN strings spends most of it. An image crossing the reservation makes the shared-cache mapping fail (dyld/SharedCacheRuntime.cpp) and the process dies before main — same failure previously hit by large-static-array binaries (Apple forums, MacPorts gcc, apache/doris). A ~500-byte binary reproduces it from VM size alone:

$ cat > pad.s <<'EOF'
.zerofill __HUGE,__huge,_pad,0x7FC00000
.globl _main
.text
.p2align 2
_main:
  mov w0, #0
  ret
EOF
$ clang pad.s -o pad && ./pad
dyld[91324]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed
dyld[91324]: Library not loaded: /usr/lib/libSystem.B.dylib

(Pad ≤ 0x7B000000 boots 8/8 runs; 0x7C000000 4/8, 0x7E000000 2/8, 0x7F000000 1/8 — the ASLR slide eating a variable slice — and ≥ 0x7FC00000 fails 8/8.)

What would be the threshold for hashing though?

A per-symbol threshold doesn't fit this failure — the problem is aggregate (3.17M debug-map entries × 475 bytes average), not any single name. We've recovered most of the budget by cutting instantiation counts on our side, which is mangling-independent. With the legacy gate going away, the residual ask is aggregate relief on Mach-O: an aggregate-triggered fallback, or an option to omit N_FUN names entirely (the full names already live in the referenced object files).