Research: Windows PE/COFF fast-linking strategy - optimize LLD-COFF fork vs retrofit COFF into Wild

[zackees]

Research: Windows (PE/COFF) fast-linking strategy — fork/optimize LLD-COFF vs retrofit COFF into Wild

Purpose

Decide, with evidence, which of two strategies reld pursues to dramatically improve Windows link performance. This issue collects the research; the decision will be recorded here once the research phases (appended as comments) are complete. macOS is explicitly out of scope for this cycle. Windows only.

The two candidate strategies

Option 1 — Fork LLD (lld-link / rust-lld) and optimize its COFF driver

Optimize for non-LTO, thin-LTO, and full-LTO regimes.

• Pro: lld-link already links Windows correctly, covering the full flag/feature surface. Every optimization is testable with a brutal, cheap oracle: does the optimized path produce a byte-identical deterministic binary vs the unoptimized path? Low bring-up risk.
• Con: presumably a lower performance ceiling — we inherit lld's architecture (memory model, serialization points, PDB pipeline).

Option 2 — Retrofit PE/COFF into the Wild linker

Wild is dramatically faster on ELF, which makes it the tempting choice.

• Pro: highest performance ceiling; modern parallel architecture; written in Rust.
• Con: Wild is ELF-only today. Windows linking has a long tail of machinery with no ELF analog (PDB/CodeView, import libraries, dllimport thunks, SEH/.pdata, /GUARD:CF, resources, manifests, delay-load). Bring-up could burn days-to-weeks of effort and heavy token spend before we even learn whether a blocker (most likely PDB) is fatal. Byte-identity testing vs lld is impossible by construction — a different linker produces different bytes — so the test oracle is weaker (behavioral equivalence).

Fixed constraints (decided up front)

1. Both toolchain flavors are in scope: MSVC (link.exe-style, *-pc-windows-msvc) and GNU/MinGW (*-pc-windows-gnu). (soldr preferred MSVC early on; we've since evolved — both now.)
2. This is a general-purpose C/C++/Rust linker. Linkers are language-agnostic: rustc emits ordinary COFF objects and .rlibs (plain ar archives whose .rmeta member a linker must skip — standard archive handling). No Rust-specific format support exists or is needed; "Rust support" = correct COFF/archive handling + accepting the flags rustc passes. (Research must verify this claim, not assume it.)
3. All link modes matter: non-LTO (dev inner loop), thin-LTO, full-LTO. Once the design is right, an agent grinds each mode until it is as fast as possible.
4. Full link.exe flag/feature compatibility is mandatory — the whole surface (/WHOLEARCHIVE, /ALTERNATENAME, /EXPORT, /DEF, /DELAYLOAD, /GUARD:CF, /DEBUG + PDB, def files, manifests, resources, …). Sole MVP exception: /INCREMENTAL may be deferred. Everything else is required.
5. CRT selection /MT vs /MD is super important and must be handled correctly (defaultlib resolution, /NODEFAULTLIB, mixed-CRT diagnostics).
6. Zig's self-hosted COFF linker is potentially super important prior art — their bring-up experience (esp. PDB) is direct evidence for the Wild-retrofit cost estimate.

Research questions

A. Scoping / baseline

• A1. Where does Windows link time actually go today (lld-link vs link.exe; symbols vs no symbols; LTO vs not)? Profile evidence, not vibes. If PDB emission dominates, that reshapes everything.
• A2. Verify constraint Meta: road to a working cross-platform link (Windows / Linux / macOS) #2: confirm rustc's linker contract on windows-msvc and windows-gnu (flags passed, rlib handling, self-contained mode, -fuse-ld/linker-flavor mechanics). Is there truly zero Rust-specific linker work?
• A3. In thin/full LTO, is link time dominated by LLVM codegen inside the LTO plugin rather than link mechanics? If yes, does linker choice even matter for LTO builds, meaning the decision should be driven by the non-LTO dev loop?

B. LLD-fork path

• B1. How fast is lld-link today vs GNU-ld/mold/wild on comparable inputs — how much headroom exists?
• B2. Where does lld-link spend time (symbol resolution, /ICF, PDB emission, LTO)? What has upstream already parallelized (e.g. parallel PDB type merging, ghash)? What serialization points remain?
• B3. Is lld-link deterministic/reproducible by default (/Brepro, timestamps, PDB GUIDs)? The byte-identity oracle depends on it.
• B4. Fork maintenance: COFF-driver churn rate upstream; can optimizations be upstreamed instead of forked; how hard is shipping a patched lld to Rust/C++ users?
• B5. What did Rust's "lld by default on Windows" efforts learn? Known blockers?

C. Wild-retrofit path

• C1. What fraction of Wild is format-generic (symbol resolution, layout, parallelism, string merging) vs hard-wired ELF (relocations, section model, dynamic linking, TLS)? Is there any abstraction boundary today, or is ELF baked into core types? This is the load-bearing feasibility question.
• C2. Has Wild upstream stated any position on COFF/PE (or Mach-O) support? Would they accept a port, or is this a hard fork of a fast-moving project?
• C3. Enumerate the COFF machinery with no ELF analog that must be written from scratch: import/export tables + import libraries, dllimport thunks, SEH/.pdata unwind, safeseh, /GUARD:CF metadata, resources (.res), manifest embedding, delay-load, TLS callbacks, base relocations, and — the monster — PDB/CodeView writing. Estimated cost of each; which can be borrowed from existing Rust crates or LLVM?
• C4. Where does Wild's speed actually come from — and does the advantage survive once COFF's costs (esp. PDB) are added? Risk: weeks of porting to land at lld-speed anyway.
• C5. What is Wild's correctness/test story, and what would our COFF test oracle be given byte-identity vs lld is impossible?
• C6. Licensing of Wild vs LLVM (Apache-2.0 WITH LLVM-exception) — any shipping constraint?

D. Prior art & third options

• D1. Zig's self-hosted COFF linker: current status, what works, what stalled, PDB story, lessons on effort. Direct evidence for Option 2's cost.
• D2. mold/sold history: mold's author split macOS support into a separate product (sold) and later abandoned it. What does that say about cross-format code sharing in a single-format fast linker?
• D3. Any other fast-COFF efforts (e.g. Microsoft's link.exe improvements, radlink, others)?
• D4. Is there a hybrid/staged option: optimize lld now (ships this cycle) while a strictly time-boxed Wild-COFF spike answers C1–C4? GNU-flavor-first as a stepping stone (avoids some MSVC machinery)?

E. Decision criteria & kill criteria (to be finalized before any build starts)

• E1. Estimated bring-up cost to a minimum viable milestone per path: links a real Rust hello-world + one mid-size real C++/Rust project on windows-msvc and windows-gnu; binary runs; tests pass.
• E2. Written kill criteria per path (e.g. Wild: "if PDB or import-library handling has no feasible design within N effort, stop"). Purpose: never discover infeasibility at the bottom of a rabbit hole.
• E3. Is byte-for-byte reproducibility a product requirement for reld (content-addressed caching) or only a testing convenience? If product: heavy thumb on the scale for lld.

Known corner-case watchlist (adversarial pass will expand this)

PDB writing (the classic underestimated monster) · /INCREMENTAL expectations (deferred for MVP but users assume it) · full link.exe flag pass-through surface · dllimport-from-static-lib fixups · CRT selection /MT vs /MD and defaultlib resolution · import library flavors (short vs long format, MinGW .dll.a) · ARM64/ARM64EC · authenticode signing space · antivirus/mmap I/O behavior on Windows · string/COMDAT merging semantics differences · /Brepro + PDB GUID determinism.

Process

1. Opus research agents gather evidence per section (LLD-COFF, Wild internals, Rust linker contract, Zig/mold prior art, link.exe compatibility surface). Each phase's findings are appended to this issue as a comment with links.
2. Fable reads all findings and runs an adversarial/follow-up pass (corner cases, feasibility gaps); follow-up research appended likewise.
3. Decision recorded as a final comment on this issue: chosen option, rationale, staged plan, kill criteria.

🤖 Generated with Claude Code

[zackees]

Research phase 1/5 — LLD COFF driver (lld-link): performance, parallelism, determinism, fork mechanics

Report from Opus research agent, 2026-08-26. All claims link primary sources; items marked unverified/speculative are the agent's inference.

Key takeaways

• The COFF driver is small and nearly free-standing: lld/COFF/ is ~22.0k LOC (17,764 .cpp + 3,805 .h + 417 .td, 38 files, measured at main on 2026-08-26). It shares zero code with lld/ELF/ — only lld/Common/ (1,291 LOC of .cpp) and LLVM libs. Churn is ~10 commits/month (2023–2025), currently dominated by ARM64EC/ARM64X and DTLTO, not by the hot path.
• Non-LTO/no-debug headroom is real but bounded. The best proxy is ELF: mold is ~1.5–4x faster than ld.lld and wild ~2.5x (MaskRay, Apr 2026). On a real 26 GB-of-OBJs Unreal Engine link, lld-link burns 259.9 s of CPU in 29.7 s of wall on 32c/64t (aganea, PR #169224, Jan 2026) — average concurrency ~8.8x out of 64 threads. (Derived by the agent from the hyperfine output; not an upstream claim.) That gap is the fork's actual target.
• On debug (PDB) links, you are not writing a linker, you are writing a type-merger. The one published phase profile shows 96.8% of an 81.9 s link is PDB emission (type merging alone 70.2%) with symbol resolution + layout + write under 3% (llvm-dev, Feb 2019).
• Type merging is already parallel; symbol merging is not. TypeMerger::mergeTypesWithGHash() uses parallelForEach/parallelFor/parallelSort and a lock-free priority-CAS hash table; PDBLinker::addObjectsToPDB() then calls addDebug() in a plain serial for loop, and the driver's input-file taskQueue is a strictly serial while (!taskQueue.empty()). Those two are the biggest remaining serialization points.
• Determinism is achievable and the mechanisms are content-hash-based, which is good news for a byte-identity oracle — but three things silently poison it: the default PE TimeDateStamp = time(nullptr), the absolute /pdbaltpath, and an EnvBlockSym in the PDB that records cwd, absolute argv[0], and the full command line. The last one means "optimized binary vs unoptimized binary" comparisons must run the same-named exe from the same path with the same argv.
• For LTO builds, linker mechanics are a rounding error. Changing only the malloc implementation moved an LTO link of clang.exe from 38m47s to 2m15s (Ganea RFC, Jul 2020); rpmalloc in-tree gave 43m40s → 1m45s on a 176-vCPU box (PR #91862). Optimizing the COFF front-end will not move LTO wall time.
• Substituting a patched lld-link for Rust on windows-msvc works today with -Clinker=, no rustc rebuild — rustc invokes the linker directly (LinkerFlavor::Msvc, no cc indirection). Name the binary anything other than lld-link/lld/rust-lld and rustc emits a clean MSVC command line with no -flavor prefix.
• Rust's windows-msvc lld tracking issue (#71520) has all six of its listed blockers closed (last one Dec 2024), and is stalled purely on "nobody has produced a Windows benchmark" — retep998, 2025-04-30. That is a gap this project could fill directly.

---

1. PERFORMANCE: how fast is lld-link, and how much headroom is left?

vs MSVC link.exe

The foundational number is Zachary Turner, Improving Link Time on Windows with clang-cl and lld, LLVM Blog, 2018-01-08:

Toolchain	Mode	blink_core.dll	content.dll	chrome.dll	clang.exe
MSVC	/DEBUG:FULL	553.11s	205.45s	507.17s	62.45s
MSVC	/DEBUG:FASTLINK	116.77s	56.05s	67.80s	29.37s
lld-link	/DEBUG:FULL	121.17s	42.10s	42.31s	24.14s
lld-link	/DEBUG:GHASH	88.71s	33.30s	34.76s	17.99s

That's 6–15x vs /DEBUG:FULL, but only 1.3–2.0x vs MSVC's own /DEBUG:FASTLINK. Chromium switched Windows to lld on the strength of this (chromium-dev, Apr 2018).

The important counter-datapoint is Alexandre Ganea (Ubisoft), Optimizing Builds on Windows, LLVM Dev Meeting, Oct 2019. On a AAA game editor (22.8 GB of MSVC .obj, 300 MB exe, 2 GB pdb, 10M type records, 42M symbols; Xeon W-2135 6c):

• VS2019 16.2 link.exe: 58 s
• LLD 9.0: 62 s — slower than link.exe
• LLD 8 + parallel GHASH: 49 s

Same deck, slide 10: with compilation cached, the linker becomes the majority of build wall time (35 s compile vs 40 s link). That is the core argument for investing here.

Independent user reports on modern link.exe agree the gap has narrowed: gulbanana, 2023-01-15: "link.exe performance seems to have improved a lot in VS2019 and VS2022 … i'm not seeing gains from switching to rust-lld." Conversely EmbarkStudios/rust-ecosystem#15 claims 2x full / 5x incremental (anecdotal, 2019, no methodology; repo archived 2026-05-21).

There is no rigorous, current (2024–2026) published lld-link vs link.exe benchmark. That is a genuine hole in the literature.

vs fast ELF linkers (the headroom bound)

MaskRay, Recent lld/ELF performance improvements, Apr 2026, clang-23 Release+Asserts, --gc-sections:

Linker	Time	vs lld
ld.lld HEAD	940.7 ms	1.00x
mold	599.4 ms	1.57x
wild	375.8 ms	2.50x

Excluding --gdb-index: mold 1.47–1.97x, wild 2.50–2.78x. Largest remaining lld deficit is parse: 320 ms lld vs 120 ms wild. The mold README table (16c/32t, debuginfo on) shows a wider 3.6–4.0x on MySQL/Clang/Chromium.

No production-grade fast COFF linker exists. mold's own Windows support is aspirational (rui314/mold#190, targeted "by mold 3.0"); the kkent030315/mold Windows fork promised an alpha by summer 2025 and shows one commit. wild is ELF-only and is explicitly noted as often slower with lots of debug info — directly relevant to a PDB-heavy COFF workload.

Estimated headroom (agent inference, marked speculative): ~1.5–3x on non-LTO links generally, with the upper end coming from (a) parallelizing PDB symbol merging and (b) parallelizing input parsing/symbol resolution. The concurrency figure below is the most defensible evidence.

The single best modern datapoint

aganea, [LLD][COFF] Prefetch inputs early-on, PR #169224, merged 2026-01-09, Unreal-Engine-based game, 4,169 OBJs / 26.3 GB non-lazy input / 350M input type records / 45.5M module symbol records, Threadripper PRO 3975WX 32c/64t:

• Warm page cache: 29.689 s ± 0.550 s wall, User 259.873 s, System 37.936 s
• Cold page cache (RAMMap eviction): 48.124 s → 34.192 s with the prefetch patch (1.41x)

Derived: 259.9 s CPU / 29.7 s wall = ~8.8x average concurrency on 64 hardware threads. If the 260 s of CPU work were perfectly parallel it would finish in ~4 s; it takes 29.7 s. Roughly 25 s of that link is not effectively parallel. That is the headroom, and it is large.

---

2. PROFILE: where the time goes, what is already parallel, what is still serial

Published phase breakdown

llvm-dev, Making LLD PDB generation faster, Feb 2019, 141 MB binary → 1.2 GB PDB:

Component	Time	%
Total link	81,900 ms	100%
PDB emission (cumulative)	79,261 ms	96.8%
— type merging	57,534 ms	70.2%
— symbol merging	10,822 ms	13.2%
Input file reading	1,724 ms	2.1%
Code layout	482 ms	0.6%

DenseMap::LookupBucketFor alone was ~35 s. Explicit note in-thread: "there is no parallelization inside of addObjectsToPDB." Ganea's 2019 deck corroborates with a CPU-utilization trace showing high parallelism only during the ghash phase, with Symbols Merge and Layout PDB running near-idle.

lld-link /time reports exactly these phases; the timer set is enumerated in lld/COFF/COFFLinkerContext.h: inputFile, lto, gc, icf, codeLayout, outputCommit, symbolGather, symbolStrings, write, then PDB: totalPdbLink, addObjects, typeMerging, loadGHash, mergeGHash, symbolMerging, publicsLayout, tpiStreamLayout, diskCommit. --time-trace= gives a Chrome-tracing profile with the same scopes.

What upstream has ALREADY parallelized

/DEBUG:GHASH was added by D40980 (Turner, 2017), then made parallel by Reid Kleckner, D87805 "[PDB] Merge types in parallel when using ghashing", 2020-09-16:

• chrome.dll type merging 2814 ms → 1269 ms; PDB emission 6691 → 4253 ms; total link 8416 → 5882 ms (30%)
• Large MSVC /Z7 build, 6-core Xeon: /DEBUG 51 s → /DEBUG:GHASH 27 s
• Trade-off: ~10% slower single-threaded (upfront record scan); break-even at 2 threads.

Ganea's earlier RFC D55585 "Parallel GHASH generation at link-time" and his dev-meeting deck track Type Merge from 19.21 s → 7.42 s → 5.29 s (8-byte buckets) → 4.20 s (8-byte + 2 MB pages).

Complete list of parallel* call sites in lld/COFF/ at main (grepped the tree):

File	Site	What is parallel
DebugTypes.cpp:1079,1081	loadGHashes()	ghash loading per TpiSource
DebugTypes.cpp:1111	ghash table insert	lock-free CAS insert
DebugTypes.cpp:1144	parallelSort(entries)	assign final type indices
DebugTypes.cpp:1182	remapTpiWithGHashes	type index remap per object
ICF.cpp:243,246,280,287	ICF	hashing + equivalence refinement
Writer.cpp:2654	sec->chunks	Chunk::writeTo (section content write)
Writer.cpp:2738	sortExceptionTable	.pdata sort
SymbolTable.cpp:647	ARM64EC __imp_ fixup	narrow
MapFile.cpp / LLDMapFile.cpp	map-file emission	not on the default path
MinGW.cpp:287	auto-export scan	MinGW only

Plus, in LLVM proper, publics layout is parallelized: GSIStreamBuilder.cpp uses parallelFor for name hashing and bucket sorting and parallelSort for Publics and the address map.

Serialization points that REMAIN (all verified by source read at main)

1. Input file / archive processing is fully serial. lld/COFF/Driver.h declares std::list<std::function<void()>> taskQueue; and Driver.cpp:1153–1159 drains it with a plain while (!taskQueue.empty()) { taskQueue.front()(); taskQueue.pop_front(); }. Only the file mapping is overlapped, via createFutureForFile / std::async (Driver.cpp:154–167) plus the new /prefetch-inputs. Symbol resolution itself is single-threaded — the same structural problem MaskRay identifies for ELF in Why isn't ld.lld faster? (ld.lld 1.22x on 8 threads vs mold 3.26x; archive semantics resist parallel resolution).
2. PDB symbol merging is serial. PDBLinker::addObjectsToPDB() (PDB.cpp:1160–1171) runs for (TpiSource *source : dependencySources) addDebug(source); then for (TpiSource *source : objectSources) addDebug(source); — no parallelForEach. addDebugSymbols() (PDB.cpp:1017) is where the 13.2% goes. rnk's D87805 explicitly flagged this as the next step ("symbol records … can be merged in parallel since they get written to independent streams") and it has not landed. This is the single most obvious win available to a fork.
3. TPI/IPI stream layout (tpiStreamLayoutTimer) and DBI module descriptor creation (createModuleDBI loop) are serial.
4. MSF/disk commit (diskCommitTimer) is a serial write.

Is lld-link multi-threaded today?

Yes, but shallowly. /threads:N sets parallel::strategy = hardware_concurrency(N) (Driver.cpp:1667–1676) and also seeds /opt:lldltojobs. Default is all hardware threads. The parallel regions are the table above; everything else is one thread.

---

3. DETERMINISM: can two runs produce byte-identical EXE + PDB?

Yes, with the right flags. The authoritative statement is Nico Weber, Deterministic builds with clang and lld, LLVM Blog, Nov 2019: "All of LLVM's tools have deterministic outputs when run with the right flags but not necessarily by default."

PE header timestamp

Source of truth, lld/COFF/Driver.cpp (config->timestamp handling) — precedence is /timestamp: > /Brepro > SOURCE_DATE_EPOCH > time(nullptr):

• Default is time(nullptr) — not reproducible.
• /Brepro sets config->repro = true; Writer::writeBuildId() then computes hash = xxh3_64bits(outputFileData) and writes the low 32 bits into both coff_file_header->TimeDateStamp and the debug-directory TimeDateStamp fields, and emits an IMAGE_DEBUG_TYPE_REPRO entry. /Brepro OFF-by-default was a deliberate 2018 change (D46966): "Using a deterministic value breaks Windows' AppCompat database in strange ways."
• /timestamp:<u32> is an lld-only extension — link.exe has no equivalent override.
• SOURCE_DATE_EPOCH is honored, added by PR #81326 (Feb 2024, LLVM 18+, backported to release/18.x). Tested in lld/test/COFF/timestamp.test.
• Caveat: /Brepro means something different in link.exe (VS2013 wrote 0xFFFFFFFF, VS2017+ writes a Build ID) — see AMOSSYS and Raymond Chen, 2024-08-15. You cannot compare timestamp bytes across the two linkers.

PDB GUID / signature / age — deterministic unconditionally

lld/COFF/PDB.cpp:1652 sets infoBuilder.setHashPDBContentsToGUID(true) always. PDBFileBuilder::commit then does:

uint64_t Digest = xxh3_64bits({Buffer.getBufferStart(), Buffer.getBufferEnd()}); H->Age = 1; memcpy(H->Guid.Guid, &Digest, 8); memcpy(H->Guid.Guid + 8, "LLD PDB.", 8); H->Signature = (uint32_t)Digest;

So the GUID is xxh3-64 of the whole PDB + the literal ASCII "LLD PDB.", Age is hardcoded to 1, and no wall-clock timestamp is written into the PDB. This replaced a random GUID in D51956 (2018). The same hash also drives the PE's CodeView record (Writer::writeBuildId, BuildIDHash::PDB/Binary). Collision risk is real but remote — one report at #54487.

The three real hazards for a byte-identity oracle

1. /pdbaltpath defaults to the absolute PDB path, made absolute and dot-removed (Driver.cpp:2627–2634), and is embedded in the PE debug directory. Use /pdbaltpath:%_PDB%.

2. Object/source paths inside the PDB are absolutized via pdbMakeAbsolute() unless /pdbsourcepath:<fixed> is given.

3. The * Linker * module's EnvBlockSym records cwd, exe, pdb, and cmd — PDB.cpp:addCommonLinkerModuleSymbols():

   • cwd = sys::fs::current_path() (or /pdbsourcepath)
   • exe = pdbMakeAbsolute(ctx.config.argv[0]) — the absolute path of the linker binary itself
   • cmd = quote(argv.drop_front()) — the full command line

   This is the trap for the byte-identity oracle. If you compare build\opt\my-lld-link.exe against build\base\my-lld-link.exe, the PDBs differ in the exe field, and because the GUID is a hash of the whole PDB, the EXE differs too. Run both binaries from the same path with the same argv and cwd, or diff with the linker module excluded.

   Good news: fillLinkerVerRecord() hardcodes the backend version to MSVC 14.10.25019 and cs.Version = "LLVM Linker" — it does not vary with lld version, and ons.Signature = 0. So a fork does not perturb these by bumping its version string.

Nondeterminism sources: essentially none in the algorithms

• Parallel type merging is deterministic by construction. GHashCell packs (isItem, tpiSrcIdx+1, ghashIdx) most-to-least significant so that operator< is a priority function, and GHashTable::insert runs a CAS loop that keeps the highest-priority cell regardless of which thread wins. Comment in source: "lower tpiSrcIdx and ghashIdx values are preferred, which means that type record from earlier sources are more likely to prevail." A final parallelSort fixes the ordering.
• ICF is deterministic: llvm::stable_sort on equivalence class, and shard boundaries are computed before any mutation (ICF.cpp:236–238 comment).
• Publics layout compensates for parallelSort being unstable with explicit name comparisons (GSIStreamBuilder.cpp:433).
• Diagnostics ordering is the one thing parallelism perturbs, and upstream considers that acceptable (LLVM Discourse; MaskRay: "Linker output needs to be predictable. There is no excuse."). /threads:1 restores it.
• Ambient hazard: LLVM's per-process hash_combine seed is an address (MaskRay, May 2026); LLVM_ENABLE_REVERSE_ITERATION exists to catch leaks into output. No COFF-specific escape is known; that none exists is unverified.
• Cross-version stability is NOT guaranteed: the .debug$H ghash format supports SHA1, SHA1_8, and BLAKE3 variants (TypeHashing.h), so PDB bytes can differ across LLVM versions. Pin the version for the oracle.

Prior art

Chromium ships byte-reproducible Windows builds using /Brepro on the compiler + /TIMESTAMP on lld-link (build/config/win/BUILD.gn). There is a long-open request to bundle the flags as one switch: #43218 "Adding /reproducible option?" (open since Nov 2019). Rust still has open Windows reproducibility bugs under rust-lang/rust#129080.

Practical oracle recipe: /Brepro /pdbaltpath:%_PDB% /pdbsourcepath:<fixed>, identical argv[0] path, identical cwd, identical arg order, pinned LLVM version.

---

4. ARCHITECTURE: how separable is lld/COFF?

Measured at main, 2026-08-26 (fetched every file and counted):

Directory	Bytes	LOC
lld/COFF/	792,534	21,986 (17,764 .cpp + 3,805 .h + 417 Options.td), 38 files
lld/ELF/	1,375,221	~3.5x COFF
lld/MachO/	861,060	—
lld/wasm/	429,425	—
lld/Common/	43,125	1,291 .cpp
lld/MinGW/	36,899	—

Code shared between COFF and ELF: effectively none. Grepped every .cpp/.h in lld/COFF/ for cross-driver includes — the only two hits are comments (CallGraphSort.cpp:9 "This is based on the ELF port"; ICF.cpp:16 "See ELF/ICF.cpp for the details"). The only shared headers are lld/Common/*:

Timer.h (9 uses), LLVM.h (9), ErrorHandler.h (7), Memory.h (5), CommonLinkerContext.h (3), Filesystem.h (2), Args.h (2), and one each of Version.h, TargetOptionsCommandFlags.h, Strings.h, Reproduce.h, DWARF.h.

bjorn3 puts it well (rust#71520, 2025-10-09): "Lld is really 4 (or 5 if you count the MinGW compat mode of the COFF linker code) separate linkers in a single executable. There is shared code, but most of it is platform specific."

Biggest COFF files: Writer.cpp 3,150 · Driver.cpp 3,031 · PDB.cpp 1,857 · InputFiles.cpp 1,584 · SymbolTable.cpp 1,519 · Chunks.cpp 1,370 · DebugTypes.cpp 1,241 · DLL.cpp 1,129.

Dispatch: one lld binary, flavor from argv[0] or -flavor; link → WinLink (lld/Common/DriverDispatcher.cpp:35).

Churn (commits touching lld/COFF, via GitHub API):

Year	COFF	ELF
2019	195	—
2020	113	—
2021	85	—
2022	59	—
2023	116	—
2024	129	441
2025	125	186
2026 (Jan–Aug)	43	—

So ~10 commits/month 2023–2025, ~5/month so far in 2026 — very manageable rebase load. Looking at the last ~45 commit subjects, the mix is: ARM64EC/ARM64X (largest bucket), DTLTO, MinGW fixes, NFC cleanups. The only perf commit in that window is aganea's /prefetch-inputs (#169224). Almost nothing upstream is touching the hot path a fork would rewrite — that materially lowers merge-conflict risk.

Maintainers: Martin Storsjö (mstorsjo) and Alexandre Ganea (aganea) (lld/Maintainers.md). Ganea is also the person who has done essentially all the COFF perf work, which is a strong signal that well-benchmarked perf patches will get reviewed upstream.

---

5. FORK MECHANICS

Licensing and build

• Apache-2.0 WITH LLVM-exception (lld/LICENSE.TXT) — permissive; a proprietary or renamed fork is legally straightforward.
• LLD_BUILT_STANDALONE is a supported build mode (lld/CMakeLists.txt:19–35): find_package(LLVM REQUIRED HINTS "${LLVM_CMAKE_DIR}"). You can build a forked lld against a stock installed LLVM instead of carrying the whole monorepo. Caveat: the PDB machinery you most want to change (PDBFileBuilder, GSIStreamBuilder, TypeHashing) lives in llvm/lib/DebugInfo/PDB/, not in lld — so a serious PDB-speed fork will need to fork LLVM too, or upstream those bits.

Release cadence

Two majors/year, ~6 months apart, RC1→final ~6 weeks, patch releases for ~24 weeks (HowToReleaseLLVM). A fork rebasing per release faces roughly 60–130 COFF commits per year, mostly in ARM64EC/DTLTO territory.

Fork vs upstream — agent assessment (opinion, marked as such)

Upstreaming is realistic for anything that is (a) benchmarked and (b) doesn't regress single-thread. D87805's history is the template: rnk landed a 30% win despite a 10% single-threaded regression, because the multi-thread numbers were compelling. Parallel PDB symbol merging is the obvious upstreamable candidate — rnk already named it as the next step and nobody has done it in 6 years.

Fork-only makes sense for changes that are semantically risky (new caching layers, incremental linking, on-disk indexes) or that require an API break in llvm/DebugInfo/PDB. A hybrid — fork for velocity, upstream the clean wins — has the lowest total cost, given the small COFF surface and low churn.

How rust-lld ships

rust-lld is bundled in the rustc rustup component (not a separate component) — see the Rustc dist step in src/bootstrap/src/core/build_steps/dist.rs. On disk (verified on rustc 1.95.0, host x86_64-pc-windows-msvc):

<sysroot>\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe           ~108 MB
<sysroot>\lib\rustlib\x86_64-pc-windows-msvc\bin\gcc-ld\lld-link.exe    ~0.31 MB
<sysroot>\lib\rustlib\x86_64-pc-windows-msvc\bin\gcc-ld\{ld.lld,ld64.lld,wasm-ld}.exe

rust-lld.exe is one copy of lld with all flavors compiled in. The 0.31 MB gcc-ld/* files are not lld — they are the lld-wrapper shim that re-execs ../rust-lld -flavor <flavor>, existing because "Windows does not support symbolic links for files."

Can a patched lld-link be substituted? — YES on windows-msvc, no rustc rebuild

windows-msvc uses LinkerFlavor::Msvc(Lld::No) (base/msvc.rs) — there is no Cc component, so rustc invokes the linker directly with MSVC-style args. Verified via rustc --print link-args on 1.95.0:

-Clinker=	Emitted invocation
(default)	"…\HostX64\x64\link.exe" "/NOLOGO" …
rust-lld	"rust-lld" "-flavor" "link" "/NOLOGO" …
…\lld-link.exe	"…\lld-link.exe" "-flavor" "link" "/NOLOGO" …
…\my-lld-link.exe	"…\my-lld-link.exe" "/NOLOGO" …

The rule is LinkerFlavor::infer_linker_hints in rustc_target/src/spec/mod.rs — exact basename match against wasm-ld, ld.lld, lld, rust-lld, lld-link. Recommendation: name the fork something other than lld-link, and rustc emits a clean MSVC command line with no -flavor prefix. (Naming it lld-link and having it be a wrapper script is a known trap: rust#160519.)

Caveat on msvc: -Zunstable-options -Clinker-features=+lld emits bare "lld" "-flavor" "link" (a PATH lookup), and -Clink-self-contained=+linker does not redirect it to the bundled rust-lld the way it does on linux-gnu. Use -Clinker=.

windows-gnu is different: x86_64_pc_windows_gnu.rs sets linker: Some("x86_64-w64-mingw32-gcc"), flavor Gnu(Cc::Yes, Lld::No) — rustc drives gcc, so you substitute via -Clink-arg=-fuse-ld=<abs-path> or bypass with -Clinker=<fork> -Clinker-flavor=ld.lld (then you supply the mingw link args yourself). *-pc-windows-gnullvm (platform-support doc) is Tier 2 with host tools and already lld-based via llvm-mingw's clang; for pure-Rust programs the doc recommends installing rust-mingw and setting rust-lld as the linker with no C toolchain.

Flag stability (verified on 1.95.0 stable)

Flag	Status
-Clinker=<path>	Stable, all targets
-Clinker-flavor=msvc|lld-link|ld.lld|…	Stable
-Clinker-flavor=msvc-lld|gnu-lld|gnu-lld-cc|…	Nightly
-Clink-self-contained=y/n/off	Stable
-Clink-self-contained=-linker	Stable only on x86_64-unknown-linux-gnu
-Clink-self-contained=+linker	Nightly
-Clinker-features=-lld	Stable only on x86_64-unknown-linux-gnu
-Clinker-features=+lld	Nightly
-Clink-arg=-fuse-ld=lld	Stable (opaque passthrough)

Conclusion: for a Rust-facing product on windows-msvc you need nothing but stable -Clinker= and a differently-named binary. That is a very low integration bar.

---

6. RUST + LLD ON WINDOWS

Linux is done. rust-lld became the default on x86_64-unknown-linux-gnu in Rust 1.90.0 (2025-09-18) via PR #140525 (merged 2025-07-09); nightly since PR #124129 (May 2024). Measured on ripgrep: incremental linking 7x faster → ~40% end-to-end reduction; from-scratch debug ~20% (blog, 2025-09-01).

Windows is stalled, but not on technical blockers. Tracking issue rust-lang/rust#71520 "Use lld by default on x64 msvc windows" (open, created 2020-04-24, last activity 2025-10-09). Its six listed blockers are all closed (verified each via the GitHub API):

Issue	Title	Closed
#68647	Linking libtest with lld-link → undefined symbols	2020-08-31
#71504	rust-analyzer segfault with lto=thin + lld-link	2020-11-26
#72145	STATUS_ACCESS_VIOLATION, TLS section alignment	2020-10-18
#81408	ACCESS_VIOLATION deref once_cell::Lazy with LTO	2022-11-09
#85642	rust-lld lacks MSVC manifestdependency .drectve	2022-03-08
#111480	rend3 ACCESS_VIOLATION, MSVC + LLD + thin LTO	2024-12-07

ChrisDenton, 2024-12-07: "With #111480 fixed, it looks like all the blocking issues are now fixed."

Note: /INCREMENTAL, ARM64, PDB/debuginfo, and dbghelp are NOT cited as blockers anywhere in #71520. If you've seen that claim, treat it as unverified — it could not be found in the primary sources.

The two live objections are:

1. Nobody has benchmarked it. retep998, 2025-04-30: "What I would like to see is a detailed side by side performance comparison of the current versions of LLD and link.exe across a variety of Rust projects. … If the performance difference is not significant, then this can be effectively shelved." This is a concrete, fillable gap.
2. Switching linkers does not remove the MSVC dependency, which was the main motivation. retep998, 2025-05-02: "The MSVC target requires VC runtime bits that are statically linked in which we cannot redistribute … the MSVC target can never be fully self contained, regardless of our choice of linker. However, you can create a new target that sacrifices the ability to statically link to C code … This new target absolutely should use LLD by default." That new target already exists as *-pc-windows-gnullvm.

Machinery is already exercised in-tree: UEFI MSVC targets already default to LinkerFlavor::Msvc(Lld::Yes) (base/uefi_msvc.rs) — the only target base with that value.

Historical Rust-on-Windows lld numbers: PR #68623 (Zoxc, 2020-02-09), linking the compiler itself — rustc_driver 226.34s → 18.5s, rustc_macros 28.69s → 7.7s, x.py build --stage 1 src/libtest 12:00 → 8:29. Note these are LTO-ish rustc links, not typical user code.

Open windows-gnu lld bug: #115985 STATUS_HEAP_CORRUPTION in rust-lld. Open msvc+lld bug: #131363 (wrong ASAN runtime). No tracking issue proposes lld-by-default for windows-gnu (unverified/nonexistent).

---

7. LTO: does linker choice even matter?

No. In an LTO link, wall time is dominated by LLVM codegen running inside the linker process — and, on Windows specifically, by allocator contention within that codegen.

The decisive experiment is Ganea, RFC: Replacing the default CRT allocator on Windows, llvm-dev, Jul 2020 — linking clang.exe with LLD + -flto on 36 cores, changing only the malloc implementation:

Allocator	Link time	Peak commit
Windows CRT heap	38 min 47 s	14.9 GB
mimalloc	2 min 22 s	19.8 GB
rpmalloc	2 min 15 s	31.9 GB
snmalloc	2 min 19 s	42 GB

A ~17x swing from swapping the allocator, same linker. Confirmed and extended by PR #91862 "Vendor rpmalloc in-tree and use it for the Windows 64-bit release" (merged 2024-06-20):

Machine	Windows Heap	rpmalloc
16c/32t Ryzen 9 5950X	10m 38s	4m 11s
32c/64t Threadripper PRO 3975WX	23m 29s	2m 11s
176 vCPU Xeon Platinum	43m 40s	1m 45s (25x)

And the smoking gun for where LTO time goes: Ganea's 2019 deck, slide 33 — linking Rainbow Six: Siege with ThinLTO via lld-link on a 36-core Xeon Gold 6140 showed 4% CPU utilization, 96% idle, serialized on RtlAllocateHeap/RtlFreeHeap, with FunctionImportGlobalProcessing::processGlobalForThinLTO, Verifier::visitMDNode, and SimpleBitstreamCursor::Read underneath. Slide 36: clean rebuild went from >1h30m to 3m57s on 36 cores by swapping in rpmalloc.

Architecturally this is expected: ThinLTO's serial thin-link step merges compact summaries, not modules (Johnson/Amini/Li, LLVM Blog, 2016-06-21; Clang ThinLTO docs). lld/COFF/LTO.cpp:143 already runs createInProcessThinBackend(heavyweight_hardware_concurrency(thinLTOJobs)).

No published percentage breakdown of "codegen vs link mechanics" inside an LTO link was found. The 17–25x allocator swings are the strongest available proxy; treat the exact split as unverified.

The one LTO lever that IS linker-side is DTLTO (Distributed ThinLTO) — the linker farms ThinLTO backend jobs out to an external distribution system (Incredibuild etc.). COFF support landed in LLVM 21 (PR #148594, merged 2025-07-20; docs), with archive support added Dec 2025 (#157043). Flags: /thinlto-distributor:, /thinlto-remote-compiler:, -fthinlto-distributor=. This is where a fork's LTO effort should go, not into link mechanics.

Conclusion: for full-LTO and thin-LTO builds, a faster COFF front-end is close to irrelevant. Scope the fork's value proposition to non-LTO (and non-LTO-with-PDB) links, plus distribution/caching for LTO.

---

8. LLD-LINK PARITY GAPS vs link.exe

The machine-readable source of truth is the tail of lld/COFF/Options.td, under the header // The flags below do nothing. They are defined only for link.exe compatibility. Verbatim list at main:

/ignoreidl · /ltcg · /assemblydebug · /nologo · /throwingnew · /editandcontinue · /fastfail · /kernel · /pdbcompress · /emitpogophaseinfo · /nocoffgrpinfo · /noexp · /novcfeature · /delay: · /errorreport: · /idlout: · /ilk: · /ltcg: · /assemblydebug: · /ltcgout: · /maxilksize: · /tlbid: · /tlbout: · /verbose: · /guardsym:

Three tiers matter — silently ignored (above), warned/degraded, and unrecognized → hard error.

Feature	Status	Evidence
/INCREMENTAL	Accepted, but it is NOT incremental linking. Config.h:344 has bool incremental = true; and it gates exactly one thing: whether the import library is rewritten when unchanged (Driver.cpp:1108–1145 — writes to a temp .lib and renames only if bytes differ). It auto-disables under /OPT:REF, /OPT:ICF, /ORDER, and /profile with warnings ("ignoring '/incremental' because ICF is enabled"). Options.td help text is literally "Keep original import library if contents are unchanged."	source read; D42716; #35265 (closed FIXED — in the import-lib sense only)
/DEBUG:FASTLINK	Unsupported; warns and downgrades: "/debug:fastlink unsupported; using /debug:full"	windows_support.html, Driver.cpp
/LTCG, /LTCGOUT	Silent no-ops. MSVC-style LTCG is not implemented; use -flto/ThinLTO.	Options.td
/EDITANDCONTINUE, /ILK:, /MAXILKSIZE:	Silent no-ops (no incremental infrastructure)	Options.td
/PDBCOMPRESS, /EMITPOGOPHASEINFO, /KERNEL, /DELAY:, /TLBID:, /TLBOUT:, /IDLOUT:, /GUARDSYM:	Silent no-ops	Options.td
/GENPROFILE, /FASTGENPROFILE	Unrecognized → parsed as an input filename, producing error: could not open '/GENPROFILE': no such file or directory. MSVC PGO instrumentation is unsupported; use LLVM PGO.	python/cpython#135287
/DRIVER and other "exotic" options	Unsupported	windows_support.html
.DEF files	Partial — only EXPORTS, HEAPSIZE, STACKSIZE, NAME, VERSION are recognized	windows_support.html
/ORDER	Supported, but disables /incremental	Options.td, Driver.cpp:2309
/FUNCTIONPADMIN, /hotpatchcompatible	Supported (with a ≥6-byte pad check)	Driver.cpp
/guard:cf, /guard:longjmp	Supported since LLD 7.0.0 (D42592). Caveat: lld's MinGW driver does not map the CFGuard flags — use -Xlink.	LLD 7.0.0 notes
/ALIGN, /INTEGRITYCHECK, /NATVIS, /DELAYLOAD, /DEPENDENTLOADFLAG, /PDBSTREAM, /PDBPAGESIZE, /PDBSTRIPPED, /SECTION, /MERGE	Supported	Options.td
Delay-load	Supported, with a known gap: no unwind info for tailMergeX64 on x64 — #59639	issue
ARM64EC	Complete as of LLD 20.1.0 (/machine:arm64ec)	lld 20.1.0 notes
ARM64X	Actively built out — TLS directory relocs (#213529, Aug 2026), multi-arch objects (#207868, Jul 2026), hybrid symbol table (#119294). It is the single largest source of COFF churn right now. No release note declaring /machine:arm64x "complete" — treat full parity as unverified.
CLR / managed objects	/ASSEMBLYDEBUG is an explicit no-op; /CLRIMAGETYPE, /CLRTHREADATTRIBUTE, /CLRSUPPORTLASTERROR are absent from Options.td and would error as input files. Full MSIL linking unsupported — unverified beyond the Options.td absence.

lld-only extensions (relevant if the fork wants parity with lld, not link.exe): /Brepro, /timestamp:, /threads:, /time, --time-trace=, /summary, /lldmap, /linkrepro:, /lldltocache, /opt:lld*, /pdbsourcepath:, /pdbstream:, /prefetch-inputs, /includeglob:, /discard-section (Apr 2026), /sectionlayout (Aug 2026), /build-id, /thinlto-distributor:.

Highest-risk gaps for anyone adopting lld-link

1. No real incremental linking. /INCREMENTAL is a compatibility shim; do not infer behavior from its acceptance. This is also the one axis where link.exe can genuinely win, and it is the explicit end-goal of the wild project on ELF.
2. Silently-ignored flags are the dangerous class — /LTCG, /EDITANDCONTINUE, /PDBCOMPRESS accept-and-do-nothing, so builds "succeed" with different semantics.
3. /GENPROFILE fails with a confusing "could not open file" error, not "unknown option."
4. /Brepro semantics differ between lld-link and link.exe — you cannot compare PE timestamp bytes across the two.

[zackees]

Research phase 2/5 — Wild linker internals: format coupling, upstream position, speed sources, maturity, borrowable COFF machinery

Report from Opus research agent, 2026-08-26. Local read-only clone used for all file/LOC evidence: reld-extern/wild @ 9e50056f5850a6b121d87938a5e8e9bdf518ec66 (workspace version 0.10.0).

Key takeaways

1. The "retrofit COFF into Wild" framing is out of date. Wild is no longer ELF-only internally: David Lattimore did a large trait-extraction refactor in early 2026, and there are now three Platform implementations in tree — ELF, Mach-O and Wasm (libwild/src/platform.rs, impl platform::Platform for Elf<C> at libwild/src/elf.rs:648, for MachO at libwild/src/macho.rs:1007, for Wasm at libwild/src/wasm.rs:6426).
2. A COFF port is already underway upstream, in-tree, with maintainer blessing. Issue #2320 "Windows support (PE/COFF): offering to build a first version" (thewh1teagle, 2026-08-02) got an explicit "in tree is definitely preferable" from Lattimore, and PR #2374 port(coff): add MSVC link.exe-style argument parsing merged 2026-08-11 (+959/−95). libwild/src/args/coff.rs is 759 lines today; libwild/src/lib.rs:269 still bails with "PE/COFF (Windows) support is not yet implemented".
3. Core is genuinely format-generic. symbol_db.rs (2290 L), resolution.rs (1737), string_merging.rs (1157), grouping.rs (474), input_data.rs (1122), file_writer.rs (453), value_flags.rs (345) contain zero references to crate::elf / object::elf. layout.rs (6325 L) has exactly 2, one of which is a test import. Roughly ~22k LOC generic core vs ~20k ELF-specific vs ~4.5k Mach-O vs ~9.2k Wasm out of 66,872 LOC in libwild.
4. Cost calibration from the two live ports: Mach-O = 4,480 lines of format-specific code, 42 port(MachO): commits over 5 months (2026-03-22 → 2026-08-20), and per the 0.10.0 changelog it still only "can link some very simple programs." Wasm = 9,189 lines, 62 commits since 2026-05, "can link a range of programs." A COFF port is plausibly a 6–12 month, multi-person effort to reach useful, and that's with the abstraction already in place.
5. Churn is high and the abstraction is still moving. 2,460 commits total, 579 in the last ~5 months, 115–140 commits/month in 2026. libwild/src/platform.rs alone has 145 commits since it was created 2026-02-16, 75 of them since the Mach-O port started. A hard fork would bleed badly; upstream contribution is strictly cheaper.
6. The correctness apparatus does not come for free. linker-diff (10,230 LOC) is described in its own docs as finding "differences between two ELF files"; Mach-O support is ~20 lines of partial header/arch handling and the Mach-O CI job sets WILD_TEST_IGNORE_FORMAT=1 to skip format checks. A COFF port needs a COFF linker-diff written from scratch, plus 221 ELF test-source dirs have no COFF analogue (Mach-O has 20).
7. PDB is the uncovered risk. Nothing in Wild, and nothing mature in the Rust ecosystem, writes linker-quality PDBs. Microsoft's own ms-pdb/pdb-rs says "THIS IMPLEMENTATION IS NOT AUTHORITATIVE AND IS NOT A REFERENCE IMPLEMENTATION." Every Wild speed advantage is on the ELF-side of a Windows link; PDB emission is the part that dominates real MSVC debug link times and has no Wild analog.
8. License is unrestrictive: MIT OR Apache-2.0, dual, standard Rust boilerplate — forking and shipping is fine.

---

1. Format coupling — what's generic, what's ELF

Verdict: the abstraction boundary exists, is real, and already has two non-ELF users. This is the single biggest correction to the premise of the question.

The boundary

libwild/src/platform.rs (1,656 LOC, created 2026-02-16) defines the whole format-abstraction surface. Traits declared there:

Line	Trait
82	Arch — CPU arch, parameterised by Platform (type Platform: Platform)
250	Relaxation
279	Platform — the file-format boundary
1037	ObjectFile<'data>
1217	SectionHeader
1244/1253/1258	SectionType / SegmentType / SectionFlags
1264	Symbol
1318/1331/1339	Relocation / RelocationSequence / RelocationList
1343	RawSymbolName
1353/1357	VerneedTable / DynamicTagValues
1361	NonAddressableIndexes
1365	SectionAttributes
1423	ProgramSegmentDef
1450	BuiltInSectionDetails
1459	Args

Platform carries ~45 associated types (type File<'data>, SymtabEntry, SectionHeader, SectionFlags, RelocationInfo, ProgramSegmentDef, Args, LayoutExt<'data>, SectionIdentityExt, GcUnit, …) plus ~40 methods (write_output_file, section_attributes, built_in_section_details, finalise_object_sizes, finalise_layout_dynamic, apply_force_keep_sections, align_load_segment_start, …). Implementors:

• libwild/src/elf.rs:648 — impl<C: ElfClass> platform::Platform for Elf<C>
• libwild/src/macho.rs:1007 — impl platform::Platform for MachO
• libwild/src/wasm.rs:6426 — impl platform::Platform for Wasm

Arch implementors: elf_x86_64.rs:53, elf_aarch64.rs:59, elf_riscv64.rs:51, elf_loongarch64.rs:33, elf_ppc64.rs:16, macho_aarch64.rs:57, wasm_wasm32.rs:33. Note the comment at platform.rs:80: "Note that implementations are file-format specific" — i.e. Arch is (format × CPU), which is exactly what a CoffX86_64 would slot into. Lattimore confirmed this design intent verbatim in PR #1653: "The idea as it current stands is that it's file-format + CPU architecture. So PeFile would implement ObjectFile, then the platform would be something like PeX86_64 with possible support for PeAarch64 at some point."

Module-by-module ELF-coupling measurement

Count of lines matching crate::elf|object::elf|linker_utils::elf per file:

File	LOC	ELF refs	Verdict
libwild/src/symbol_db.rs	2290	0	fully generic
libwild/src/resolution.rs	1737	0	fully generic
libwild/src/string_merging.rs	1157	0	fully generic (generic over platform::Platform)
libwild/src/input_data.rs	1122	0	fully generic
libwild/src/grouping.rs	474	0	fully generic
libwild/src/file_writer.rs	453	0	fully generic
libwild/src/parsing.rs	359	0	fully generic
libwild/src/value_flags.rs	345	0	fully generic
libwild/src/archive.rs	218	0	fully generic (own ar reader)
libwild/src/program_segments.rs	108	0	generic over platform::ProgramSegmentDef
libwild/src/layout.rs	6325	2 (linker_utils::elf::RelocationKind at :83; crate::elf::Elf64 at :5989 inside mod test)	effectively generic
libwild/src/output_section_id.rs	1284	2	near-generic
libwild/src/layout_rules.rs	821	4	near-generic
libwild/src/part_id.rs	183	1	near-generic
libwild/src/platform.rs	1656	4 (DynamicRelocationKind, RelocationKindInfo, crate::elf::PropertyClass at :123, object::elf::SectionFlags at :245)	leaks, but small and named

linker_utils::elf::RelocationKind (linker-utils/src/elf.rs:407) is a semantic relocation-kind enum (Absolute, Relative, Got, SymRelGotBase, PltRelGotBase, TlsGd, …) — the module name is historical, not a coupling. Only a couple of variants embed a raw object::elf::RelocationType (e.g. PairSubtractionULEB128). macho.rs has 0 refs to linker_utils::elf; wasm.rs has 0; macho_writer.rs has 2. That's direct evidence the residual leakage is tolerable for a new format.

LOC split (libwild = 66,872 LOC total)

Bucket	LOC	Files
ELF-specific	~20,349	elf.rs (6745), elf_writer.rs (6165), args/elf.rs (2489), linker_script.rs (2483), version_script.rs (1184), gdb_index.rs (859), elf_x86_64.rs (648), elf_riscv64.rs (537), writable_elf.rs (461), elf_aarch64.rs (455), sframe.rs (338), elf_loongarch64.rs, elf_ppc64.rs
Wasm-specific	9,189	wasm.rs (7963), wasm_writer.rs (636), args/wasm.rs (480), wasm_wasm32.rs (110)
Mach-O-specific	4,480	macho.rs (2250), macho_writer.rs (1324), args/macho.rs (428), macho_aarch64.rs, macho_stub_library.rs
COFF-specific (today)	759	args/coff.rs — arg parsing only
Generic core + abstraction	~21,908	layout.rs, symbol_db.rs, resolution.rs, platform.rs, string_merging.rs, output_section_*, part_id.rs, grouping.rs, file_writer.rs, input_data.rs, parsing.rs, layout_rules.rs, symbol.rs, value_flags.rs, hash.rs, trie.rs, fs.rs, args.rs

So roughly 33% generic core / 30% ELF / 20% other-format ports / rest shared infra. The generic third is the third that matters most (parallel symbol resolution, layout graph, string merging, archive handling) and it is already format-agnostic.

Known impedance mismatches for COFF specifically

• No program segments. Lattimore, #2320: "The biggest different that I know of with Windows is that it doesn't have program segments and just relies on sections. But I'm sure that can be accomodated, albeit possibly with some interface tweaks." Mitigation already partly built: program_segments.rs is generic over ProgramSegmentDef, and Platform::align_load_segment_start is overridable.
• COMDAT. Issue #235 "Implement COMDAT support" is open since 2024-12-10. mati865 there: "It's out of scope for now, but one day, if wild gains Windows support, it will need COMDATs." COFF IMAGE_COMDAT_SELECT_* is not optional on Windows — this is a required, currently-absent core feature.
• Module structure is unresolved. Lattimore in #1653: "I've thus far avoided having submodules... I'm not quite sure why I'm so reticent to have subdirectories... it'd be good to have somewhat of a plan. e.g. do we put all the elf stuff in one directory and all the pe stuff in another." Today only args/ is a subdir.
• Lattimore's own dissatisfaction with the boundary (#1653): "I'm not entirely happy with the Platform / ObjectFile relationship at the moment... My main annoyance at the moment is the invariant lifetimes that arise from it." And: "currently its very much caters to elf" → "Yeah. My rough plan was make it less ELF-specific as we go." Expect churn in the interface you'd be porting against.

---

2. Upstream position and churn

Stated position: pro, in-tree, incremental PRs

Issue #2320, Lattimore, 2026-08:

"In tree is definitely preferable. Doing significant work outside of the tree is likely to lead to merge conflicts if changes need to be made to common infrastructure - and they almost certainly will. Also, we prefer to review code in manageable chunks."

"I wouldn't say that the codebase is ELF throughout. I did a lot of refactoring earlier in the year to move much of the ELF-specific code behind traits. Since then there has been substantial porting work done. We currently have both a wasm port and a MachO port under way... I'd hope that a Windows port could use the abstraction."

"I'd suggest leaving incremental until after we have reasonably complete support."

"The first goal with any new port I think should be to get to the point where we can link a very basic program then execute that program from the test framework... Possibly a good first PR is argument parsing."

That last suggestion is exactly what shipped as #2374. So the port is following the maintainer's own prescribed sequence.

Caveats on upstream reception

• MSVC flavor has no maintainer champion. mati865 (maintainer), #2320: "MSVC doesn't matter to me (just like I bother with Mac OS or reviewing LLM made contributions)." And in #1653: "Personally I don't care about MSVC toolchains, but I can help with MinGW part." If your target is windows-msvc, expect thin review bandwidth; if windows-gnu (MinGW), you get an active maintainer.
• Unresolved driver design. mati865, #2374 thread: "It's not yet decided how we want to handle MSVC/GNU argument handling: wire up them both separately, or mimic LLD where MinGW driver takes ELF style args and translates them to link.exe ones." Also flags the Windows path-escaping/response-file quoting problem.
• AI-contribution policy is enforced. CONTRIBUTING.md has an explicit "LLM / AI use policy" (human in the loop; don't send PRs you don't understand; don't paste LLM-written review replies), and mati865 has demanded disclosure on at least one PR (#1653). Relevant if you plan agent-assisted porting.
• Governance is formal now. GOVERNANCE.md: 4 maintainers (davidlattimore lead, lapla-cogito, marxin, mati865); major decisions go through the wild-linker/rfcs repo with 7-day majority votes; monthly video meetings; Zulip at wild.zulipchat.com. A COFF port is plausibly RFC-scale.
• Repo has moved: github.com/davidlattimore/wild → github.com/wild-linker/wild (Cargo.toml repository = "https://github.com/wild-linker/wild").

Churn rate — high, and hitting exactly the files you'd depend on

Commits/month (full history, 2,460 commits since 2024-02-05):

2025-01  86   2025-07  37   2026-01   70   2026-07  115
2025-02 132   2025-08  47   2026-02   93   2026-08  129
2025-03 109   2025-09  40   2026-03  140
2025-04  85   2025-10  82   2026-04   76
2025-05  58   2025-11  79   2026-05  109
2025-06 133   2025-12  48   2026-06  119

Files changed most in the last 90 days (libwild/src + linker-utils/src):

92 wasm.rs        54 elf_writer.rs      26 macho_writer.rs   20 args/elf.rs
64 elf.rs         49 platform.rs        26 linker_script.rs  19 lib.rs
57 layout.rs      27 output_section_id.rs  25 args/wasm.rs   19 args.rs
55 macho.rs       23 layout_rules.rs    20 wasm_writer.rs    14 symbol_db.rs

platform.rs: 145 commits since 2026-02-16 (28 in Feb, 47 in Mar, then 11–18/month). 75 commits touched platform.rs since the Mach-O port began on 2026-03-22, out of 579 total commits in that window. Translation: the format-abstraction interface changes roughly weekly, driven by whichever port is currently pushing on it.

Fork verdict: a hard fork of Wild for COFF is a bad trade. You'd be rebasing against ~120 commits/month, ~13/month of which are on the exact trait surface your port implements. Upstream contribution is the only economically sane path, and upstream has explicitly asked for it.

Releases are roughly quarterly: 0.3.0 (2024-12-03), 0.4.0 (2025-03-01), 0.5.0 (2025-05-14), 0.6.0 (2025-09-23), 0.7.0 (2025-11-04), 0.8.0 (2026-01-16), 0.9.0 (2026-05-24), 0.10.0 (2026-08-04).

---

3. Where the speed comes from, and what survives on Windows

Author-stated sources

From DESIGN.md (45 lines, the canonical short statement):

• Phase pipeline with immutable back-borrowing: args.rs → input_data.rs (mmap + archive split) → string_merging.rs → symbol_db.rs → resolution.rs → layout.rs → elf_writer.rs. "Each phase borrows data immutably from the previous phases." That is the zero-copy discipline that makes the parallelism safe.
• Rayon everywhere, with hand-rolled job control for graph phases: "Where possible, we use functions like rayon's par_iter... In a couple of cases however, we have graph algorithms that don't fit neatly into rayon's model. In those cases, we spawn one rayon scoped task per thread and then do job control ourselves." Expanded in Graph Algorithms in Rayon (2025-11-27).

From Wild Performance Tricks, RustForge 2025-09-02 — six named techniques, all format-agnostic:

1. Contiguous per-object SymbolId allocation + split_off_mut so each thread gets a disjoint mutable slice — no synchronisation, good cache locality.
2. sharded-vec-writer — parallel initialisation of uninitialised heap capacity, no placeholder-fill pass.
3. Atomic ↔ non-atomic in-place Vec conversion, exploiting identical layout — the conversion "becomes a no-op and is optimised away."
4. reuse_vec<T,U>() buffer recycling across loop iterations.
5. Deallocating large buffers on a rayon worker so the critical path isn't blocked by free().
6. MaybeUninit lifetime-stripping to move non-'static buffers to another thread for drop.

Plus mimalloc in the workspace deps.

String merging

libwild/src/string_merging.rs:1-27 documents a two-phase, thread-alternating bucket-hash algorithm using PassThroughHashMap/PreHashed and crossbeam_queue::ArrayQueue. This is what the clang-debug benchmark measures — "Clang with debug info has massive quantities of debug strings that need to be deduplicated." Wild deliberately skips suffix merging (March 2024 update) — a work-avoidance choice.

Archive semantics

Wild ignores --start-group/--end-group entirely (libwild/src/args/elf.rs:223-225: "Just like other modern linkers, we don't need groups in order to resolve cycles"). Archive member activation is decided in the parallel resolution.rs phase, not by an ordered multi-pass sweep. Wild ships its own zero-copy ar reader (libwild/src/archive.rs, 218 LOC).

mmap / output strategy

libwild/src/fs.rs + file_writer.rs: inputs mmapped (memmap2), output is an mmapped MmapMut written in parallel. FileReplacementMode has three modes — UnlinkAndReplace, UpdateInPlace, UpdateInPlaceWithFallback (default), retrying as UnlinkAndReplace on ETXTBSY. New in 0.10.0: defaults to --no-mmap-output-file on btrfs/vfat.

What survives on Windows COFF — assessment (partly speculative, flagged)

Survives unchanged (high confidence — proven format-agnostic by Mach-O/Wasm):

• Parallel symbol DB construction, sharded slices, atomic tricks (symbol_db.rs, 0 ELF refs).
• Parallel archive-member resolution. Windows .lib static archives are the same ar-family format; archive.rs needs MSVC-variant long-name/second-linker-member handling but is 218 lines.
• String/constant merging (COFF merge semantics ride on COMDAT + .rdata$... grouped sections; the bucket-hash algorithm is content-based).
• Layout graph traversal / GC (layout.rs, 2 ELF refs).
• mmap input — Wild already builds on windows-latest in CI (.github/workflows/ci.yml:184, build-only).

Degrades or is lost on Windows (speculative where marked):

• PDB emission has no analog and is not optional for the MSVC toolchain. Speculation, but well-grounded: in a /DEBUG MSVC link, PDB writing is typically the dominant cost. Wild's advantages are all on the object-graph side; a from-scratch PDB writer means Wild's Windows numbers are gated by code that doesn't exist and has never been optimised. /DEBUG is currently in the "recognised and ignored" list in PR #2374.
• In-place output-file update is far riskier on Windows (mapped/loaded images are locked; no clean unlink-open-file). Precedent: Mach-O had exactly this class of problem — #2375 code-signature SIGKILL → #2391 Use UnlinkAndReplace for outputs.
• Antivirus / Defender real-time scanning taxes every write/close. Unverified — no measurement found. Note Wild's own benchmarks are all output-to-tmpfs, the most favourable possible I/O; published margins are upper bounds even on Linux, more so on NTFS.
• Base relocations and import/export tables are net-new output-side work with no ELF counterpart. Modest.
• COMDAT selection (#235, open) is genuinely absent, and COFF leans on it far harder than ELF leans on section groups.

---

4. Maturity

What it links today

From README.md "What's working?": x86-64 / ARM64 / RISC-V / LoongArch64 (initial) / PPC64LE (initial), all on Linux. Static non-PIE, static-PIE, dynamic executables, shared objects. Rust proc-macros; "Most of the top downloaded crates on crates.io have been tested with Wild and pass their tests"; debug info; partial linker scripts; linker-plugin LTO with known open issues. Self-hosting since 0.6.0; Chromium since 0.6.0 (~1.4 GiB with debug info); librustc-driver, zed, rust-analyzer, clang, bevy-dylib (>500k dynamic symbols), mold itself all benchmarked. 0.9.0: Linux kernel modules; compressed debug info; aarch64 range-extension thunks. Firefox: unverified — no claim found. Maintainer hedge (0.6.0): "Wild is still intended primarily for fast development."

What's missing

README "What isn't yet supported?", roughly sorted by current priority: Incremental linking → more complex linker scripts → Mach-O support → Windows support. Windows is last on the stated priority list.

Incremental linking: designed-ish, not started. Issue #184 open since 2024-11-08; design write-up is Designing Wild's incremental linking (2024-11-19); ~21 months with no implementation. Lattimore told the COFF contributor explicitly to leave incremental alone until COFF support is reasonably complete.

Port status per 0.10.0 changelog (2026-08-04): "The Wasm port can now link a range of programs. Mach-O still has a way to go, but can link some very simple programs." Both behind non-default cargo features (wasm, macho, wip).

Test suite approach — expensive to replicate for COFF

DESIGN.md: compiles C/C++/Rust/asm programs, links with reference linkers (GNU ld, sometimes LLD), links with Wild, compares with the custom linker-diff tool, then executes the binaries. Concretely:

• wild/tests/integration_tests.rs — 7,848 LOC harness.
• Test sources by format: elf = 221 dirs, wasm = 61, macho = 20. COFF starts at 0.
• linker-diff/ — 10,230 LOC; its own docs: finds "differences between two ELF files." Mach-O support is ~20 lines. No COFF/PE support at all. The arch-level asm diffing (iced-x86) transfers to COFF x64; the header/symtab/segment/reloc comparators do not.
• The Mach-O CI job sets WILD_TEST_IGNORE_FORMAT=1 (format checks relaxed). Expect the same crutch for COFF v1.
• External suites vendored as submodules: mold tests + lld tests (external_test_suites/lld → wild-linker/lld-tests, wired up 2026-08-15 by PR #2399, ELF only). Silver lining: lld/test/COFF/ exists upstream and the vendoring machinery is now in place — a COFF port could bootstrap a large conformance suite for little harness work; likely the single highest-leverage move available.
• CI matrix: 6 Linux jobs, 1 wasm, 1 macOS Mach-O, 1 windows-latest build-only job.

---

5. License

MIT OR Apache-2.0, dual. No constraint on forking or shipping, including closed-source (attribution + license text; Apache-2.0 patent grant). Inbound=outbound, no CLA. GOVERNANCE.md wind-down note transfers project assets to the Rust Foundation if Wild ends — trademarks/infrastructure, not a code-license constraint.

---

6. Dependencies — what COFF machinery can be borrowed

Wild's object parsing

object (gimli-rs) 0.40.0, workspace-pinned, features ["compression", "elf", "macho", "read_core", "std", "unaligned", "archive", "names"] (+write_std in libwild). coff and pe are NOT enabled — enabling them is a one-line change. ELF output is written by hand (writable_elf.rs, 461 LOC + zerocopy), not via object::write — a COFF writer would be hand-rolled the same way using object::pe::* struct definitions. Also: gimli (DWARF read), iced-x86 (x86-64 disassembly in linker-diff — transfers to COFF), symbolic-demangle (handles msvc demangling upstream, lightly verified), winnow, zerocopy 0.8.

What the object crate already gives you for COFF/PE (verified on docs.rs 0.40.0)

• object::read::coff — CoffFile (unified Object trait), CoffHeader abstracting pe::ImageFileHeader and pe::AnonObjectHeaderBigobj (bigobj covered), sections, symbols, relocations, COMDAT group handling.
• object::read::coff::ImportFile — short imports in import libraries are parseable today (side API).
• object::read::pe — PeFile etc. for reading PE executables (needed for a COFF linker-diff and reading DLL exports).
• object::write::coff + object::write::pe — raw-struct-level writers handling "both relocatable and executable files."
• Archive reading covers the MSVC .lib variant.

Bottom line: parsing/emission plumbing is mostly borrowable — a meaningfully better starting position than the Mach-O port had.

What is NOT borrowable

• PDB / CodeView writing — the big hole.
  • pdb (getsentry): read-only. pdb2: read-oriented fork.
  • ms-pdb / microsoft/pdb-rs: "reading, creating, and modifying PDB files", MIT — but "THIS IMPLEMENTATION IS NOT AUTHORITATIVE AND IS NOT A REFERENCE IMPLEMENTATION", no support commitment, no claim of linker-grade from-scratch PDB generation.
  • pdb-sdk: pure-Rust read+write, hobbyist-scale, unverified for linker use. bao-pdb: narrow scope.
  • Assessment (speculative but confident): none is a drop-in "link N objects' CodeView into one PDB with a working type-index merge and correct hash streams" library. LLD's PDB.cpp + DebugTypes.cpp type-merging (TpiSource, GHASH, precomp//Zi) is arguably a bigger project than the COFF linking core itself.
• .res → .rsrc conversion (cvtres). No Rust crate does it (embed-resource/winresource shell out to rc.exe/windres). From scratch.
• .def parsing / export-table + import-library generation (/IMPLIB). No crate; from scratch (modest).
• SEH / .pdata / .xdata unwind handling for x64 — from scratch.
• A COFF linker-diff — ~10k LOC of ELF-shaped verification to re-create.

---

7. Performance numbers

Source: benchmarks/ryzen-9955hx.md, regenerated for 0.10.0 (2026-08-04). AMD Ryzen 9 9955HX 16C/32T, 92 GiB RAM, output on tmpfs. Comparators: LLD 21.1.8, mold 2.40.4/2.41.0, GNU ld 2.46. Percentages are the published chart labels (baseline = Wild); ms figures derived by the agent from SVG bar geometry (±2%, not official).

Workload	GNU ld 2.46	LLD 21.1.8	mold 2.41.0	Wild 0.10.0	Wild vs mold
chrome	—	6208 ms (+519%)	2063 ms (+107%)	995 ms	2.07×
chrome-crel	—	6208 ms (+497%)	2192 ms (+111%)	1032 ms	2.11×
chrome-arm64	—	28184 ms (+815%)	6789 ms (+123%)	3079 ms	2.23×
clang-debug (string-merge bound)	—	7684 ms (+207%)	3579 ms (+43%)	2505 ms	1.43×
clang-debug-strip	—	4145 ms (+907%)	900 ms (+119%)	403 ms	2.19×
clang-release	—	497 ms (+400%)	226 ms (+128%)	99 ms	2.28×
librustc-driver	—	1172 ms (+360%)	575 ms (+126%)	253 ms	2.26×
zed-debug	—	5684 ms (+735%)	1595 ms (+134%)	679 ms	2.34×
zed-release	—	2289 ms (+212%)	1132 ms (+55%)	730 ms	1.55×
rust-analyzer	—	976 ms (+763%)	284 ms (+152%)	113 ms	2.52×
bevy-dylib (500k+ dynsyms)	—	2629 ms (+775%)	1745 ms (+480%)	300 ms	5.80×
ripgrep	451 ms (+1365%)	92 ms (+199%)	61 ms (+99%)	30 ms	1.99×
mold-gdb-index	9737 ms (+4068%)	789 ms (+246%)	342 ms (+55%)	211 ms	1.55×
wild (self-link)	1512 ms* (+2551%)	207 ms (+288%)	107 ms (+99%)	53 ms	2.02×
c-hello-world	21 ms (+92%)	20 ms (+81%)	16 ms (+51%)	11 ms	1.51×
rust-hello-world	53 ms (+272%)	27 ms (+89%)	24 ms (+69%)	14 ms	1.69×
wild-lto ⚠️	12784 ms (+6%)	11384 ms (−5%)	11126 ms (−8%)	12011 ms	0.93× — Wild loses

* GNU ld figure from the wild-debug chart.

Headline: roughly 2× faster than mold and 3–9× faster than LLD across most real workloads, on 32 threads with tmpfs output.

Caveats that matter for a Windows decision:

• Wild's own benchmarks, tmpfs-only. Windows/NTFS + Defender lands worse for everyone but plausibly worse for Wild specifically (mmap-write-to-file is a bigger share of its critical path).
• The LTO case is a wash or a loss — compiler backend dominates.
• Wild's own gains have flattened. 0.10.0 changelog: "Not much changed in terms of performance." The big non-incremental wins appear spent; the next step-change is incremental linking, unimplemented and deliberately deferred behind COFF completeness.
• Parallelism shape (March 2024, 4-core): factor 2.75× — "more parallelism than LLD's, but not as much as Mold's."

---

Sources

wild-linker/wild (README, DESIGN.md, GOVERNANCE.md, CONTRIBUTING.md, CHANGELOG.md, benchmarks/, libwild/src) · #2320 Windows support · PR #2374 coff arg parsing · PR #1653 design discussion · #235 COMDAT · #184 incremental design · Wild Performance Tricks · Graph Algorithms in Rayon · 0.6.0 post · incremental design post · object 0.40 read::coff · object 0.40 write · microsoft/pdb-rs · MaskRay — Linker notes on PE/COFF

[zackees]

Research phase 3/5 — The rustc↔linker contract on Windows: verifying "linkers need zero Rust-specific support"

Report from Opus research agent, 2026-08-26. Empirical claims verified against rustc 1.94.1 (windows-gnu host), 1.97.0-nightly (windows-msvc host), and rustc main.

Key takeaways

• The claim is ~85% true, with two hard exceptions. rustc hands a Windows linker ordinary COFF objects, ordinary ar archives, and ordinary link.exe-/GNU-ld-style flags. But a correct linker must parse .drectve sections (for /DEFAULTLIB: from MSVC CRT objects and, since PR #158294, for /EXPORT: from rustc's own symbols.o), and must honor IMAGE_SCN_LNK_REMOVE (that's how lib.rmeta disappears).
• rlibs are plain archives passed straight to the linker — no extraction, except under fat/thin LTO where rustc rewrites the archive first. Empirically, libcore-*.rlib on windows-msvc is a COFF/MSVC-format archive (two / symbol-table members); on windows-gnu it is a GNU-format archive (one / member). archive_format is "coff" vs default "gnu".
• lib.rmeta is a valid COFF object, not raw bytes: machine 0x8664, one .rmeta section with characteristics 0x00100800 (IMAGE_SCN_LNK_REMOVE), one @feat.00 absolute symbol. Verified by parsing shipped rlibs from both toolchains.
• rustc relies on lazy-archive semantics as a correctness contract, not just performance: it deliberately injects a synthetic symbols.o full of undefined references so rlib members get pulled in, precisely because --whole-archive is too expensive (#93791) and -u/EXTERN() would make them GC roots (#47384). A linker that eagerly loads archive members, or that treats undefined symbols in an input object as GC roots, breaks Rust semantics.
• The MSVC flag surface is small and boring; the full observed command line for a hello-world exe is 12 distinct flags. Nothing exotic. /NODEFAULTLIB is never passed on windows-msvc by default (deliberately — see §6).
• windows-gnu is materially a second linker implementation, mostly because of import libraries. MinGW libkernel32.a = 1751 full COFF objects with .idata$*; Windows SDK kernel32.Lib = 1396 short-format import objects (Machine==0, Sig2==0xFFFF) + 3 real objects. Plus: direct-.dll linking, positional .def inputs, auto-import + runtime pseudo-relocs (both default-ON in ld and in LLD's MinGW driver), .dll.a naming, -Bstatic/-Bdynamic state machine.
• Linker substitution has a nasty naming gotcha: rustc infers flavor from the file stem. Name your binary lld, lld-link, or rust-lld and rustc will invoke it as <path> -flavor {link,gnu} …. Name it anything unrecognized on a windows-gnu target and rustc keeps the target default Gnu(Cc::Yes, …) — i.e. it treats you as a gcc driver and sends -Wl,-prefixed args and -lfoo.
• Response files differ by flavor: MSVC gets UTF-16LE with a BOM, one arg per line, each arg "-quoted with \" escaping; GNU gets raw bytes with \-escaping of \ and space.

---

1. RLIB handling

Is an .rlib a plain ar archive?

Yes. Written by ArArchiveBuilder on top of the ar_archive_writer crate (a Rust port of LLVM's ArchiveWriter). Format chosen by target.archive_format: windows-msvc → "coff"; windows-gnu → default "gnu".

Empirical confirmation (parsed the shipped rlibs directly):

	first members	symbol tables
libcore-*.rlib (1.97-nightly, msvc)	/(41604B), /(40526B), //, lib.rmeta/, /0	two (linear + MSVC sorted) → COFF/MSVC layout
libcore-*.rlib (1.94.1, gnu)	/(46116B), //, lib.rmeta/, /0, /58	one (/) → GNU layout

rustc is tolerant on input: archive_kinds_compatible explicitly allows Gnu ↔ Coff ("GNU and COFF archives share the same magic and member header format; only the symbol table layout differs") — a mismatch is a warning. In practice either symbol-table layout works, but a linker must read both.

Passed directly, or extracted?

Passed directly — "Linking to a rlib involves just passing it to the linker (the linker will slurp up the object files inside)" (add_upstream_rust_crates). Only exception: fat/thin LTO without linker-plugin-lto, where rustc rebuilds the archive into tmpdir, dropping lib.rmeta and LTO-folded objects. Confirmed via --print link-args: every rlib appears verbatim as a bare path for both msvc and gnu. whole_archive: false — rustc never whole-archives rlibs (the only whole-archive use is sanitizer runtimes).

Must the linker tolerate the non-object members?

The .rmeta member needs no special-casing — it is a legal COFF object:

MSVC libcore lib.rmeta: machine=0x8664 nsec=1 nsym=1
   sec '.rmeta' chars=0x00100800 (IMAGE_SCN_LNK_REMOVE)
   sym '@feat.00'

Matches metadata.rs::create_wrapper_file: COFF wrapper objects use IMAGE_SCN_LNK_REMOVE. Hard requirement: honor IMAGE_SCN_LNK_REMOVE (0x00000800) — emit it and every binary bloats; error on it and every link fails. Also present: absolute @feat.00 symbol (bit 0 set on i386 for /SAFESEH compat, #96498).

Other members possible: lib.rmeta-link (rustc main only), bundled native static libs (.bundled_lib wrapper objects), and — Windows-specific — raw-dylib import-library archives appended into the rlib (ab.add_archive(...); see §5). Bytecode remnants are gone in modern rustc.

---

2. Flag surface — x86_64-pc-windows-msvc

Real output from rustc --print link-args (1.97-nightly), hello-world exe:

link.exe /NOLOGO …\symbols.o <cgu objects> <13 rlibs verbatim>
kernel32.lib kernel32.lib kernel32.lib ntdll.lib userenv.lib ws2_32.lib dbghelp.lib
/defaultlib:msvcrt /NXCOMPAT /OUT:hello.exe /OPT:REF,NOICF /DEBUG /PDBALTPATH:%_PDB%
/NATVIS:…\intrinsic.natvis /NATVIS:…\liballoc.natvis /NATVIS:…\libcore.natvis /NATVIS:…\libstd.natvis

cdylib adds /DEF:…\lib.def (moved to the very front), /DLL, /IMPLIB:mylib.dll.lib.

Complete emitted-flag inventory from impl Linker for MsvcLinker: /NOLOGO, /OUT:, /DLL + /IMPLIB:<out>.dll.lib (note the .dll.lib double extension), /DEF: (on main the file is an empty LIBRARY\nEXPORTS\n stub kept only because "link.exe otherwise skips the import library for DLLs with no exports"; pre-1.96 it contained the full EXPORTS list), /WHOLEARCHIVE: (only for +whole-archive native libs), bare name.lib positionals, /LIBPATH:, /OPT:REF,ICF / /OPT:REF,NOICF (NOICF at opt-level 0 — "MSVC's ICF … is slow for Rust"), /DEBUG (unconditional, even at -Cdebuginfo=0), /PDBALTPATH:%_PDB%, /NATVIS:, /NXCOMPAT, /SUBSYSTEM: + /ENTRY:mainCRTStartup (only with #![windows_subsystem], per RFC 1665), /guard:cf / /guard:ehcont (opt-in), /INFERASANLIBS (ASAN with real link.exe only).

Nothing exotic. No /EXPORT: on the command line (moved into .drectve on main), no /MANIFEST, /ORDER, /ALIGN, /BASE, /MACHINE, /STACK, /INCREMENTAL, /SAFESEH, /DYNAMICBASE.

link.exe is located via VS discovery only when neither -Clinker nor the target-spec linker is set — so -Clinker=<your.exe> cleanly bypasses it. rustc sets VSLANG=1033/LC_ALL=C on the child for English diagnostics.

---

3. Flag surface — x86_64-pc-windows-gnu

Default flavor is Gnu(Cc::Yes, Lld::No) with linker: Some("x86_64-w64-mingw32-gcc") — rustc drives gcc, not ld, and there is no rust-lld default. Real output (1.94.1):

x86_64-w64-mingw32-gcc -fno-use-linker-plugin -Wl,--dynamicbase -Wl,--disable-auto-image-base
-m64 -Wl,--high-entropy-va …\symbols.o <cgu objects>
-Wl,-Bstatic <20 rlibs> -Wl,-Bdynamic
-lkernel32 -lkernel32 -lkernel32 -lntdll -luserenv -lws2_32 -ldbghelp
-lgcc_eh -l:libpthread.a -lmsvcrt -lmingwex -lmingw32 -lgcc -lmsvcrt -lmingwex -luser32 -lkernel32
-Wl,--nxcompat -o hg.exe -Wl,--gc-sections -no-pie -nodefaultlibs

Direct-ld self-contained mode (-Clinker-flavor=ld -Clinker=ld -Clink-self-contained=yes) is the same content in GNU-ld spelling plus the CRT startup object crt2.o from lib\rustlib\...\self-contained\.

Notes:

• --enable-auto-image-base is NOT used — rustc passes --disable-auto-image-base ("ASLR will rebase it anyway"). Plus --dynamicbase, --nxcompat, --high-entropy-va, -m i386pep.
• -Bstatic/-Bdynamic state machine applies: rlibs arrive under -Bstatic, system libs under -Bdynamic. A linker must track it.
• --out-implib=libfoo.dll.a for dylib/cdylib; --gc-sections for executables; -nodefaultlibs always (windows-gnu spells its libs out explicitly, listed twice on purpose — "mingw's msvcrt is a weird hybrid import library and static library", PR #47483).
• Export lists are a positional .def file (list.def, EXPORTS\n "name"[ DATA]), not --version-script. LLD's MinGW driver special-cases positional *.def inputs into -def:. A GNU-flavor Windows linker must accept a .def path as a positional input.
• --enable-auto-import / --enable-runtime-pseudo-reloc are never passed by rustc but default ON in binutils ld and LLD's MinGW driver. Real MinGW libraries need them.
• CRT objects: crt2.o/dllcrt2.o in self-contained mode (pre_mingw_self_contained()); otherwise gcc supplies them. The shipped windows-gnu sysroot is a complete MinGW installation (crt objects, libgcc/libmingwex/libmsvcrt + 30 import libs, plus bundled ld.exe, dlltool.exe, x86_64-w64-mingw32-gcc.exe).
• rust-lld is shipped but not default for windows-gnu; -Clinker-features=+lld / -Clink-self-contained=+linker are stable only on x86_64-unknown-linux-gnu.
• *-pc-windows-gnullvm is a third variant: linker: Some("clang"), -nolibc --unwindlib=none, no libgcc, CfgAbi::Llvm (which notably disables the dlltool path in §5).

---

4. Linker selection

Three knobs: -Clinker=<path>, -Clinker-flavor=<flavor>, cargo [target.<triple>].linker (passed through as -C linker; there is no [target.*].linker-flavor — flavor must go through rustflags).

Windows-relevant flavor spellings: msvc (stable), lld-link (stable legacy → Msvc(Lld::Yes)), ld (stable legacy → raw GNU-ld flags — the practical way to get raw-ld flags on windows-gnu today, verified working on stable 1.94.1), gcc/ld.lld (stable legacy), msvc-lld/gnu/gnu-cc/gnu-lld/gnu-lld-cc (unstable).

Gotcha 1 — flavor is inferred from the linker's file stem (infer_linker_hints)

• Named lld, lld-link, rust-lld, ld.lld, wasm-ld → invoked as <path> -flavor {link|gnu} … — the binary must accept -flavor as argv[1].
• Named anything unrecognized (reld, myld) → target default wins. On windows-msvc that's Msvc(Lld::No) (clean link.exe-style args — good). On windows-gnu that's Gnu(Cc::Yes, …) — rustc treats the binary as a gcc driver (-Wl, args, -lfoo). Pass -Clinker-flavor=ld explicitly.
• Named *-ld → raw GNU-ld flags with no CLI flag needed. Trailing -<digits> version suffixes are stripped before matching.
• .bat names get wrapped as cmd /c.

Gotcha 2 — response files

Triggered near the ~32768-char Windows spawn limit or on E2BIG; rustc writes <tmpdir>\linker-arguments and re-spawns with @<path>.

flavor	rule
MSVC-like (also any LLD flavor on a Windows host)	one arg/line, "-wrapped, \" escaping, UTF-16LE + BOM
GNU	raw bytes, \-escape of \ and space

A linker taking -Clinker-flavor=msvc must parse UTF-16LE-with-BOM @-files.

Gotcha 3 — no version probing, but stderr sniffing

rustc never runs the linker with --version (retry-on-failure covers -no-pie/-fuse-ld=lld/-static-pie, all Gnu(Cc::Yes) only). It does pattern-match linker stderr for the linker-messages lint; custom linkers fall into the generic path — harmless.

---

5. Rust-specific edge cases a linker must get right

5a. The synthetic symbols.o — the real Rust-ism

add_linked_symbol_object emits an object passed first on the link line. Two jobs:

1. Undefined references to every linked_symbol, forcing lazy-archive pull-in — deliberately instead of --whole-archive (too expensive, #93791) or -u (would create GC roots, #47384). Contracts that fall out: (a) lazy archive semantics; (b) an undefined symbol in a regular input object must not become a /OPT:REF GC root.
2. .drectve /EXPORT: directives (MSVC, rustc main/1.96+ via PR #158294): /EXPORT:"name"[,DATA][,EXPORTAS,"other"] — quoted names and the ARM64EC-era EXPORTAS keyword included. The object always carries an empty .text ("MSVC will hang if the input object file contains no sections").

Version boundary: rustc ≤1.95 wrote a full EXPORTS .def and passed /DEF: — no .drectve from rustc (confirmed empirically on 1.97-nightly: symbols.o has no .drectve; exports are in lib.def). main has flipped. Support both shapes.

5b. #[link(kind = "raw-dylib")] — the linker sees a normal import library

rustc synthesizes it on disk (<tmpdir>\<dll>.dll_imports.lib) and passes the path like any other library. Two producers:

• MSVC: ar_archive_writer::write_import_library — verified 7-member COFF archive: __IMPORT_DESCRIPTOR_*, __NULL_IMPORT_DESCRIPTOR, *_NULL_THUNK_DATA real objects + short-format import objects (Sig1=0, Sig2=0xFFFF). rustc passes the /WHOLEARCHIVE-compat flag true because of #129020 — duplicate __NULL_IMPORT_DESCRIPTOR-family symbols across import libs must be deduped, not errored.
• MinGW: shells out to dlltool (is_using_dlltool: windows && gnu && CfgAbi::Unspecified) because "the binutils linker … cannot read the import libraries generated by LLVM" (produced AV-crashing exes). Result is a GNU archive of full COFF head/tail/per-symbol objects (_head_*, *_iname, fthunk) — no short imports at all.

Also: on Windows the raw-dylib import libs are added into the rlib archive itself, so an rlib can legitimately contain import-library members, short-format objects included.

5c. dllimport/dllexport for Rust dylibs

• rustc does not use LLVM dllexport; exports arrive via .drectve /EXPORT: (msvc, main) or .def (gnu, and msvc pre-1.96).
• Consuming a Rust dylib: MSVC — rustc links <path>.dll.lib if present, silently nothing otherwise. GNU — rustc puts the .dll path itself on the command line: a GNU-flavor linker must support linking directly against a PE DLL (binutils "direct linking to a dll"; search order libxxx.dll.a → … → xxx.dll).
• dll_tls_export: false on both bases (rustc never exports TLS symbols from a Windows DLL).

5d. Debuginfo / NATVIS

Only /DEBUG + /PDBALTPATH:%_PDB% + /NATVIS:<file> — but /NATVIS means the linker must embed .natvis XML into the PDB or Rust types render as raw bytes in debuggers. msvc: DebuginfoKind::Pdb, SplitDebuginfo::Packed only. gnu: DWARF in-image, no split.

5e. Unwinding / SEH — nothing beyond correct COFF (verified by object dump)

• Every .text/.rdata/.xdata/.pdata in a rustc-msvc object is IMAGE_SCN_LNK_COMDAT; COMDAT selection incl. IMAGE_COMDAT_SELECT_ASSOCIATIVE (tying .pdata/.xdata to .text) is mandatory and exercised hard (one COMDAT per function).
• Rust panic=unwind on MSVC uses MSVC C++ EH funclets (__CxxFrameHandler3, $cppxdata$, $stateUnwindMap$, $ip2state$) — ordinary symbols, no special handling.
• Standard PE .pdata requirement: merge COMDATs and sort by BeginAddress. requires_uwtable: true.
• windows-gnu x86_64 also uses SEH (libgcc_s_seh); i686-pc-windows-gnu uses DWARF-2 unwinding (.eh_frame, libgcc_s_dw2) — extra machinery if 32-bit gnu matters. eh_frame_header: false (no --eh-frame-hdr).

5f. Symbol names — just names

v0 (_R…) and legacy (_ZN…) manglings are plain ASCII identifiers. Only requirement: don't truncate long names (Rust symbols routinely exceed 100 chars — archive // longnames member and COFF string table are exercised constantly). i386 stdcall decoration is applied by rustc, not the linker.

---

6. CRT selection on windows-msvc

The /MT-vs-/MD choice is made by core via a #[link] hack (library/core/src/ffi/mod.rs):

#[link(name = "/defaultlib:msvcrt", modifiers = "+verbatim", cfg(not(target_feature = "crt-static")))]
#[link(name = "/defaultlib:libcmt", modifiers = "+verbatim", cfg(target_feature = "crt-static"))]

Verified: default → /defaultlib:msvcrt; -Ctarget-feature=+crt-static → /defaultlib:libcmt. Because of +verbatim it arrives as a raw lowercase argument — handle /DEFAULTLIB: case-insensitively on the command line and in .drectve.

/NODEFAULTLIB is never emitted by default on windows-msvc — windows_msvc.rs sets no_default_libraries: false with this rationale (the single best primary-source statement of the .drectve requirement):

// We don't pass the /NODEFAULTLIB flag to the linker on MSVC as that prevents linker
// directives embedded in object files from including other necessary libraries.
// For example, msvcrt.lib embeds: /DEFAULTLIB:vcruntime.lib /DEFAULTLIB:ucrt.lib

Confirmed: a COFF linker MUST parse .drectve. vcruntime.lib and ucrt.lib are never on rustc's command line; they arrive only via directives inside msvcrt.lib's members. windows-gnu is the mirror image: -nodefaultlibs is always emitted and every mingw lib is spelled out explicitly.

The .drectve directive set to implement (LLD's accept-list, tokenized "using Windows shell rules"): /EXPORT:, /DEFAULTLIB:, /NODEFAULTLIB:, /INCLUDE:, /EXCLUDE-SYMBOLS:, /ALTERNATENAME:, /ALIGNCOMM:, /ENTRY:, /SUBSYSTEM:, /STACK:, /SECTION:, /MERGE:, /RELEASE, /FAILIFMISMATCH:, /MANIFESTDEPENDENCY:, plus accepted-and-ignored /EDITANDCONTINUE, /GUARDSYM:, /THROWINGNEW, /INFERASANLIBS; anything else errors. Rust objects don't emit /FAILIFMISMATCH:, but any C/C++ static lib linked into a Rust binary will.

---

7. Dual-flavor reality: is windows-gnu a second linker?

Substantially yes. Shared: PE/COFF writing, COMDAT, relocations, .pdata sorting, base relocs, archive reading, .def parsing, IMAGE_SCN_LNK_REMOVE. Different:

Axis	windows-msvc	windows-gnu
Command-line dialect	/FLAG:value, case-insensitive, @utf16 response files	--flag/-l/-L, -Bstatic/-Bdynamic state machine, @utf8 response files
Archive symbol table	two / members (COFF layout)	one / member (GNU layout)
Import libraries (measured)	SDK kernel32.Lib = 1396 short-import objects + 3 real	mingw libkernel32.a = 1751 full COFF objects, head/tail (_head_*, *_iname), zero short imports
Import-lib naming	foo.lib, implib foo.dll.lib, /IMPLIB:	libfoo.dll.a search chain, --out-implib=
Direct .dll linking	not supported	required (rustc passes upstream Rust .dlls positionally)
Import descriptor dedupe	__NULL_IMPORT_DESCRIPTOR family (#129020)	dlltool-style, different symbols
Auto-import / pseudo-relocs	n/a	default ON; needs __RUNTIME_PSEUDO_RELOC_LIST[_END]__ synthesis + _pei386_runtime_relocator cooperation
CRT startup	via .drectve /DEFAULTLIB:	explicit crt2.o/dllcrt2.o + mingw lib list (duplicated on purpose)
Unwinding	SEH funclets, .pdata/.xdata	x86_64: SEH; i686: DWARF-2 (.eh_frame)
Debuginfo	PDB + /NATVIS	DWARF in-image
Exports	.drectve /EXPORT: (+ empty /DEF:)	positional list.def

Agent's read: LLD's own structure is the honest answer — lld/COFF/ is one linker and lld/MinGW/Driver.cpp is a ~700-line argument translator into the same COFF core. That's the proven architecture: one backend, two front-ends, plus genuinely new backend work for (a) both import-library styles, (b) direct-DLL linking, (c) auto-import + runtime pseudo-relocs, (d) DWARF unwinding for i686-gnu. "One binary, two flavors" is achievable, but "windows-gnu is free once msvc works" is not.

---

Caveats / unverified

• Version skew is real. The .drectve /EXPORT: mechanism (PR #158294, merged 2026-07-01) is on rustc main but not in 1.94/1.95/1.97-nightly (those still write a full EXPORTS .def). lib.rmeta-link is likewise main-only. A linker must handle both shapes for several releases.
• The .drectve directive set above comes from LLD's implementation (the de-facto reference); the exact MS-documented short-import NameType semantics were not verified against a Microsoft primary source (LLVM's COFFImportFile.cpp / ar_archive_writer are the practical references).
• Whether link.exe accepts a GNU-format rlib in practice (rustc's archive_kinds_compatible asserts it, warning-only) was not measured empirically; likewise ld with a COFF-format rlib.

[zackees]

Research phase 4/5 — Prior art: Zig's COFF linker, mold/sold, lld's own COFF history, PDB ecosystem, radlink, effort calibration

Report from Opus research agent, 2026-08-26.

Key takeaways

• Zig has been trying to ship a self-hosted COFF linker since 2018 and still has not. It has been written from scratch twice (kubkon, Aug 2022; jacobly0, Oct 2025 — +9274/-14124, deleting the 2022 one), is still not the default on any Windows target, and emits no debug info at all: current master contains exactly one PDB reference, the comment // TODO: Convert .debug$* sections into PDB (src/link/Coff.zig:4478). Zig still ships LLD for every release build, including Windows.
• The "PDB is the monster" thesis is well supported. lld's section-based COFF linker was working and default within ~3 months of starting (May→Aug 2015), but lld docs said "The PE/COFF port is almost complete except the lack of the Windows debug info (PDB) support" through lld 5.0 and lld 6.0 and only flipped to "complete, including Windows debug info (PDB) support" in lld 7.0 (Sept 2018). COFF linking: months. COFF + PDB: ~3 years.
• Cross-format code sharing in a fast linker is ~6%, empirically. rui314's sold (mold + Mach-O) is the cleanest natural experiment: elf/ 861 KB, macho/ 324 KB, common/ 77 KB — the Mach-O side was a second linker written from scratch sharing only glob/tar/mmap/cmdline scaffolding. After sold was abandoned, mold deleted the format split entirely and is a flat ELF-only src/ again.
• rui314 explicitly declined to build a PE/COFF linker, twice, on economics not difficulty — "it would cost me 6 to 7 figures in terms of opportunity cost" (mold#190) and "I don't have a plan to work on a PE linker… you may want to try LLVM lld, which I originally wrote before" (mold#1052).
• A fast COFF+PDB linker already exists, is open source, and is MIT-licensed: Epic's radlink, ~1.5 MB of C, first shipped Oct 2024, and as of Aug 2026 was still landing /OPT:ICF, DEF files, and COMDAT weak-symbol handling — ~22 months in and still filling in MSVC-parity basics.
• PDB writing is no longer LLVM-exclusive. Microsoft now publishes microsoft/pdb-rs (MIT, Rust, actively developed, "supports reading, creating, and modifying PDB files"), and PascalBeyer/PDB-Documentation ships a from-scratch write_pdb.c (108 KB) + toy COFF linker. The old microsoft/microsoft-pdb spec repo has been archived since 2023-04-27 and was never complete.
• In every prior fast-linker project, PDB/debug-info emission is comparable in size to the entire rest of the linker. radlink: ~416 KB of 866 KB linker dir. PascalBeyer: write_pdb.c (108 KB) > linker.c (83 KB). LLVM: PDB+CodeView+MSF libs ≈ 1.27 MB vs lld/COFF at 792 KB.
• Wild's maintainer has already given design direction for a COFF port in wild#2320 (Aug 2026): in-tree, use the existing platform.rs trait abstraction (Mach-O and wasm ports already underway on it), PDB deferred, incremental deferred, "a number of PRs before a trivial program could be run".

---

1. Zig's self-hosted COFF linker

Status today (Zig master, Aug 2026)

⚠️ Zig migrated to Codeberg in Nov 2025; the GitHub repo is frozen at 2025-11-27.

Fact	Evidence
Self-hosted COFF linker is src/link/Coff.zig, 310,316 bytes / 7,751 lines	Codeberg src/link
No PDB/CodeView output. Only PDB mention: // TODO: Convert .debug$* sections into PDB	src/link/Coff.zig:4478
Not robust enough to be default: selfHostedBackendIsAsRobustAsLlvm returns true only for .elf	src/target.zig:298
LLD still default for all release builds and for Windows debug builds	src/Compilation/Config.zig:359,419
The 0.16.0 release notes Linker section (2026-04-14) is titled "New ELF Linker" and mentions COFF zero times; even the new ELF linker "lack[s] DWARF information"	release notes

The timeline (8 years, two from-scratch rewrites, still not shipped)

• 2018-09-17 — #1535 "create a self-hosted incremental linker", andrewrk: "This is a huge project — support has to be explicitly added for every target OS and every target architecture."
• 2021-05-09 — #8726 "completely eliminate dependency on LLD"; still open.
• 2022-08-29 — #12677 "coff: initial rewrite of the COFF/PE linker" (kubkon). Milestone: "we can correctly link and execute a very crude and hacky program" — raw NtTerminateProcess syscall, hardcoded _start.
• 2023-10-27 — #17751 "eliminate dependency on LLD for COFF/PE"; still open. Flags the .res→COFF (cvtres-equivalent) dependency.
• 2025-06-08 — devlog: x86 backend default in Debug "not changed on Windows yet, because more COFF linker work needs to be done first."
• 2025-10-01→03 — #25430 "Coff2: create a new linker from scratch" (jacobly0), +9274/-14124 — the 2022 linker deleted wholesale.
• 2026-06 — 38-commit burst by kcbanner tripling Coff.zig: symbol-table rework, weak externals, dll-import handling, absolute-symbol relocs, import thunks, .ctor/.dtor, .bss merging, archive second-linker-member alignment, 32-bit fixups. The "actually link real object files" phase, ~8 months after the rewrite landed.
• Incremental: #21165 — "this linker is currently buggy" (sporadic Windows race condition per jacobly0).
• PDB: #6031 "Emit PDB along with PE files" — open since 2020-08-11 with zero comments. Zig reads PDBs (lib/std/pdb.zig) but has never written one.

What Zig's experience says about the COFF effort curve

• Easy/fast: PE headers, section layout, base relocations, import tables/IAT, trivial _start exe (single PR).
• The long tail (years): archive/import-library semantics, weak externals, COMDAT selection, aliases, __imp_ handling, entry autodetection, thunks, .ctor/.dtor, resource conversion, MinGW-vs-MSVC dual ABI — exactly the 2026-06 commit list, arriving 4 years after "we can link a program."
• The monster nobody touched: PDB. Eight years in, still a comment.

Person-years (estimate — ⚠️ not stated by any source): calendar span 8 years; concentrated engineering ~1.5–3 developer-years (kubkon 2021–2024, jacobly0 2025, kcbanner 2026; 362+ commits touching Coff.zig). Order-of-magnitude only.

---

2. mold / sold — the cross-format-sharing lesson

Timeline (primary sources)

Date	Event
2020-09-29	mold repo created
2021-11-27	mold/macOS "pre-alpha… can't link any program other than… hello world" (#132)
2021-12-23	rui314 files #189 macOS (by mold 2.0) and #190 Windows (by mold 3.0)
2022-11-18	bluewhalesystems/sold created
2022-12-26	mold 1.8.0 removes macOS support entirely → sold (release notes)
2023-01-24	rui314 closes the Windows issue: "I'll support it in the sold linker instead"
2023-07-26	mold 2.0.0 relicensed AGPL→MIT: dual-licensing monetization "didn't meet our expectations"
2024-06-03	"The plan is no further development for macOS either on sold or mold" (#1052)
2024-11-25	last push to sold; repo now archived. README: Apple shipped its own new linker; "I recommend using that instead."

How much code could actually be shared? ~6%.

sold is the only fast linker that ever shipped two formats in one tree:

Directory	Bytes
elf/	861,005
macho/	324,409
common/	76,866 (6.1% of total)

And common/ is utilities (glob, tar, compress, uuid, demangle, filepath, output-file, perf), not linking. Each format has its own mold.h (84 KB vs 34 KB), main.cc, input-files.cc, output-chunks.cc, cmdline.cc, and per-arch relocation backends. rui314 wrote a second linker essentially from scratch. The postscript: today's mold src/ is a flat, ELF-only tree — the multi-format split was deleted once sold died.

This mirrors his 2015 argument for splitting lld's ports (LLD improvement plan, llvm-dev): "the symbol resolution semantics are not the same on three architectures… but we only have one 'core' linker" — the ports would share less code, on purpose.

rui314 on Windows/COFF for mold — repeatedly negative, on economics

From #190, #1052, #1069:

2022-07-06: "The core part has to be written by me (or by someone who… has extremely deep knowledge of the Windows linker) to achieve our performance goal."

2023-01-24: "it would cost me 6 to 7 figures in terms of opportunity cost… I've already wrote lld for Windows (that's my first linker)… If you are not happy with sold, you can always use lld."

2023-07-27: "I suspect Microsoft is already working on their own version of faster linker, and if that's the case, no third-party linker can compete with it… I don't want to risk wasting my time to work on a non-competitive product."

The objection is never "COFF is too hard" — it's (a) opportunity cost, (b) lld already exists, (c) fear of being obsoleted by the platform vendor. (c) transfers directly to the reld decision.

---

3. LLD's own COFF history — how big is COFF, really?

• Pre-2015: lld had an atom-based PE/COFF linker (Rui's "first linker") — so lld's COFF was also written twice.
• 2015-05-01: LLD improvement plan — Rui projects "a PE/COFF linker in a few weeks, which works reasonably well", explicitly because he'd built one before.
• 2015-05-29 (r238458): section-based COFF linker lands; self-links, "1.2 seconds vs 5 seconds… 250MB of RAM to self-link vs 2GB."
• 2015-08: new COFF default. 2015-07: ELF port derived from the COFF architecture.
• 2017-08: LLVM blog — PDB support, Zachary Turner: "After about a year and a half of studying this code, hacking away…"; "alpha in terms of debug info quality."
• 2018-01: clang-cl+lld blog: PDB generation "by far the slowest" part.
• 2018-09 (lld 7.0): "The PE/COFF port is complete, including Windows debug info (PDB) support."

Calibration: COFF linking ≈ 3 months for the world expert on his second attempt. COFF to MSVC parity including PDB ≈ 3.3 years wall-clock, with the PDB half alone ~1.5–2 person-years by a specialist (Turner) plus Kleckner et al. — with Microsoft's partial source dump. Current sizes: lld/COFF 792 KB (of which PDB.cpp 71 KB + DebugTypes.cpp 48 KB) — the smallest of lld's three mature ports. COFF-the-format is genuinely simpler than ELF; it's the debug format that isn't.

---

4. PDB/CodeView specifically

How hard, in bytes

Component	Size
llvm/lib/DebugInfo/CodeView + headers	292 KB + 289 KB
llvm/lib/DebugInfo/PDB/Native + headers	344 KB + 170 KB
llvm/lib/DebugInfo/MSF + headers	38 KB + 23 KB
Total PDB/CodeView machinery	≈ 1.24 MB — 1.6× the entire lld/COFF linker

Corroboration from a minimal implementation: PascalBeyer/PDB-Documentation — toy linker linker.c 83 KB next to write_pdb.c 108 KB + msf.c 22 KB. The PDB writer is bigger than the linker. (Plus 222 KB validate.c — validation is itself a project.)

Is microsoft-pdb still the only spec? No — and it never was sufficient.

• microsoft/microsoft-pdb — archived 2023-04-27; "only able to upload a subset"; "didn't compile… half of it was missing" (LLVM blog).
• LLVM's PDB docs — best prose spec, self-described work-in-progress; PascalBeyer: "really good [but] incomplete… minor mistakes."
• PascalBeyer/PDB-Documentation (2023–2025) — most complete public write-up (MSF, info stream, /names, TPI/IPI, DBI, module streams, GSI/PSI, CodeView records). Snapshot pinned to MSVC 19.28.
• microsoft/pdb-rs (MIT, created 2024-10-18, pushed 2026-08-24) — the big change since 2018: Microsoft's own Rust crates, ms-pdb-msf ("reading, creating, and modifying" MSF), ms-pdb ("supports reading, creating, and modifying PDB files"), plus codeview/ and coff/ crates. Caveats in-repo: "NOT AUTHORITATIVE… NOT A REFERENCE IMPLEMENTATION", no compat guarantees. ⚠️ Unverified: whether ms-pdb can emit a from-scratch, linker-grade PDB (full TPI/IPI type merge, GSI/PSI hash streams, section contributions, line info) vs only modifying existing PDBs. This is the single highest-value follow-up check for any Rust COFF linker — the difference between "reimplement 1.2 MB of PDB machinery" and "wire up a vendor-authored MIT crate."
• Other independent PDB code: raw_pdb, dump_syms, willglynn/pdb, getsentry/pdb (all readers); EpicGamesExt/raddebugger (reader and writer — §5).

Could a non-LLVM linker link against LLVM's PDB libraries?

Technically yes — llvm/lib/DebugInfo/{PDB/Native,CodeView,MSF} is portable C++ with no Windows API dependency ("100% portable", LLVM blog), and lld/COFF/PDB.cpp is the reference consumer. The cost is inheriting LLVM as a build dependency — the exact thing Zig spent 8 years escaping ("The Zig compiler binary goes from about 150 MiB to 5 MiB", #16270). ⚠️ Speculation: for a Rust linker, FFI to libLLVMDebugInfoPDB is mechanically feasible but likely more painful than ms-pdb, because LLVM's writer API is intertwined with lld's own DebugTypes.cpp type-merging/GHASH machinery rather than being a clean standalone "write me a PDB" entry point.

---

5. Other fast-COFF efforts

radlink (RAD / Epic Games) — public, MIT, the most relevant prior art

Lives in EpicGamesExt/raddebugger (MIT, 7.4k stars); first shipped v0.9.13-alpha, 2024-10-18 — "an in-progress drop-in replacement for MSVC's linker." README: "designed to be very fast when creating gigantic executables… generates standard PDB files… command line syntax is fully compatible with MSVC"; ~50% faster link times on multi-GB debug info; /rad_large_pages another ~25%; no LTO yet.

Code size (a hard reference for "COFF+PDB from scratch, done properly"):

Module	Bytes
src/linker/ (incl. lnk.c 299 KB, lnk_config.c 134 KB, lnk_debug_info.c 131 KB, pdb_ext/ 211 KB, codeview_ext/ 74 KB)	866 KB
src/codeview	219 KB
src/coff	194 KB
src/pe	165 KB
src/pdb + src/msf	72 KB
≈ total COFF/PE/PDB surface	≈ 1.5 MB of C

Effort signal: v0.9.28-alpha, 2026-08-21 — 22 months after first ship — is still landing /OPT:ICF, DEF/SECTION support, COMDAT weak-symbol fixes, import/export edge cases, forwarder detection. A well-funded expert C team took ~2 years from launch to /OPT:ICF, still alpha.

Microsoft's own link.exe

• /DEBUG:FASTLINK (VS2015u1→VS2022): ~2× inner loop; deprecated and removed in VS2026 — "/DEBUG:FULL linking times have improved significantly, and /DEBUG:FASTLINK isn't always faster."
• VS2019 linker fundamentals: "/debug:full is typically 3X-6X and up (10X wins on some workloads)" — from data-structure/cache work and memoization, not parallelism ("link.exe is fundamentally a serial process (mostly)"). This is the concrete form of rui314's fear that Microsoft closes the gap.

"lld as default on Windows"

lld-link won the third-party fight (Chromium default since 2018, Firefox), but has never shipped incremental linking — the stated trade-off at Chromium switch time. Incremental remains the one axis where link.exe is unbeaten, and is exactly the eventual Wild differentiator (deferred by Wild upstream until COFF is complete).

Rust ecosystem

No production COFF linker in Rust exists. Wild's README lists Windows support dead last in priority. On wild#2320 the contributor's v1 scope explicitly excludes PDB ("Debug info is by far the biggest and least documented part of a Windows linker"), and Lattimore's guidance: in-tree, use the trait abstraction, defer incremental, "a number of PRs before a trivial program could be run." Co-maintainer mati865: "MSVC doesn't matter to me" — MinGW/GNU-flavored COFF may get more maintainer buy-in in Wild than MSVC-flavored. Format friction reference: MaskRay, Linker notes on PE/COFF.

---

6. Effort calibration

⚠️ Everything here is synthesis/estimate; the mapping onto "team with heavy AI-agent labor" is the agent's inference.

What consumed calendar time in each prior effort

Effort	Cheap phase	Expensive phase	What actually ate years
lld COFF (2015)	3 weeks to a working linker (by the author of the previous one)	Aug 2015 → Sept 2018 to parity	PDB/CodeView + type merging (~1.5 yr specialist to "alpha quality", plus GHASH perf work)
Zig COFF (2018–now)	days to _start-only exe (2022)	2022→2026 object-file/archive/COMDAT/weak/import semantics	MSVC-compat long tail; PDB never started
sold Mach-O (2021–24)	hello world in months	never left alpha → abandoned	A whole second linker; only 6% shared
radlink (2024–now)	shipped alpha <1 yr with PDB	22 months to /OPT:ICF, still alpha	MSVC parity edge cases + ~40% of the linker being debug-info code

(a) Optimize an existing correct COFF linker (lld fork)

Effort class: 1–3 engineer-quarters to first credible win; correctness budget ~zero. Start at 100% MSVC parity and PDB output; the work is pure perf engineering on a known-serial codebase (parallel PDB symbol merging, parallel input parsing, GHASH-by-default, allocator, mmap output). This is the option AI-agent labor helps least relative to a human expert (perf work is measurement-bound, not typing-bound), but the only option whose risk is bounded. Two headwinds: (i) the hot path is PDB.cpp/DebugTypes.cpp — surgery on the hardest 15% of the code; (ii) Microsoft closed a 3–6× link.exe gap between VS2017 and VS2019 by pure data-structure work.

(b) COFF+PDB bring-up in a new/retrofitted linker (e.g. Wild)

Effort class: multiple engineer-years, dominated by two subsystems that are not the linker.

1. Plumbing + trivial exe — weeks (trait abstraction already exists; "a number of PRs before a trivial program could be run").
2. Real MSVC objects, archives, import libs, COMDAT, weak externals, thunks, exports/DEF, /OPT:REF — 1–2 engineer-years per Zig 2022→2026 and radlink 2024→2026. Broad, shallow, spec-following, heavily testable against lld-link diffs — the single best fit for AI-agent labor in this entire problem; an agent fleet plausibly compresses 18 months to 4–6.
3. PDB/CodeView writing — the discontinuity. ~1.2 MB in LLVM, ~416 KB in radlink, 108 KB even in a toy. Turner needed ~1.5 years with Microsoft's source dump to reach "alpha quality." Under-specified (only official spec repo archived and incomplete), oracle is "does VS/WinDbg behave correctly," and failures are silent — a structurally valid PDB that misplaces line info debugs subtly wrong. AI-agent labor helps least here (bottleneck is ground-truth validation against a closed debugger, not code volume). ⚠️ The one lever that could collapse this: if ms-pdb (microsoft/pdb-rs) can genuinely construct a linker-grade PDB, this line item drops from years to months. Verify before costing option (b).
4. Type-merging performance — even after PDB works, making it fast is a separate project (GHASH, .debug$H); per LLVM it is "by far the slowest" part of a Windows link. A COFF linker that is fast at everything except PDB is a COFF linker that is not fast.

Bottom line

The two options are not two points on one curve — they're different projects:

• (a) buys speed against a fixed, already-correct target; the risk is competitive (Microsoft, and lld itself, may be good enough).
• (b) buys ownership and an incremental-linking future — the one thing lld-link has never done and the one thing Windows developers still keep link.exe for — but pays for a debug-info implementation that has defeated or been deferred by every fast-linker project except Epic's: Zig deferred it 8 years, Wild's proposed port defers it explicitly, mold refused the format entirely, lld took 3 years with a dedicated specialist and Microsoft's source.

A defensible hybrid no source rules out (⚠️ agent inference): do (b) for the linking core inside Wild's trait abstraction and acquire PDB as a dependency (ms-pdb, or LLVM's DebugInfo libs) rather than building it — the whole history above is the argument for why that boundary is the one worth buying.

[zackees]

Research phase 5/5 — The full link.exe compatibility surface: flags, .drectve, CRT, import/export, Windows metadata, COMDAT semantics, determinism

Report from Opus research agent, 2026-08-26. .drectve/CRT claims verified locally against VS2022 BuildTools with dumpbin.

Key takeaways

• The link.exe surface is ~120 documented options (full list), but the subset a C/C++/Rust toolchain actually exercises is ~45. lld-link's Options.td is the best available spec of that subset: ~130 implemented, 27 accepted-and-ignored under an explicit "flags below do nothing" banner, and the CLR/WinMD/MIDL/PGO families simply unknown (warn, not error).
• .drectve is the load-bearing mechanism, not the command line. Every MSVC object carries /DEFAULTLIB, /FAILIFMISMATCH, /alternatename, /EXPORT directives, and CRT import libraries themselves carry further /DEFAULTLIB and /FAILIFMISMATCH records (verified locally with dumpbin). /MT-vs-/MD correctness is not a command-line feature — it is a fixed-point algorithm inside the linker's archive-loading loop, and cannot be bolted on afterwards.
• /MT vs /MD requires exactly two mechanisms: transitive /DEFAULTLIB resolution during lazy archive member loading, and a global key=value map for /FAILIFMISMATCH fed from both command line and every .drectve encountered (lld's whole implementation is ~12 lines, Driver.cpp:684-698). S/M difficulty — the risk is architectural (when directives are processed), not algorithmic.
• The genuinely hard, Windows-only, no-ELF-analogue work is: PDB/CodeView emission (XL), CFG/load-config table synthesis (L), delay-load thunk synthesis (M/L), import-library short-format parsing + __imp_ thunk synthesis (M), and .rsrc tree construction from .res (M). lld/COFF is ~752 KB of source across 37 files (Writer.cpp 114 KB, Driver.cpp 106 KB, PDB.cpp 69 KB, DebugTypes.cpp 46 KB) on top of LLVM's DebugInfo/{MSF,CodeView,PDB}, Object/COFF, WindowsResource and WindowsManifest libraries.
• ELF layout logic transfers at maybe 40-60%. The resolve→GC→ICF→assign-addresses→relocate→write pipeline is identical in shape. But COFF COMDAT has six selection kinds including SELECT_LARGEST/SELECT_SAME_SIZE/SELECT_EXACT_MATCH and associative chains where ELF SHT_GROUP has only "same signature → keep one"; COFF has no SHF_MERGE (string dedup rides on COMDAT); and $-suffix section ordering (.text$mn, .CRT$XCU, .gfids$y) is a lexical-sort layout rule with no ELF equivalent.
• Determinism is cheap on the image and expensive on the PDB. /Brepro is ~6 lines in lld. Byte-reproducible PDBs additionally require deterministic GUID/Age, /pdbsourcepath, /PDBALTPATH:%_PDB%. Ecosystem tolerance is proven (Chromium/Firefox ship this); one known caveat (tools parsing the timestamp as a date) has the /timestamp: escape hatch.
• MinGW is a second linker persona, not a flag translation. Auto-import + runtime pseudo-relocs require emitting a __RUNTIME_PSEUDO_RELOC_LIST__ table and CRT cooperation (_pei386_runtime_relocator); plus auto-export-all, --kill-at, stdcall fixup, .ctors/.dtors sentinels, a different default-merge table.
• Directly relevant: Wild's checkout already contains libwild/src/args/coff.rs (759 lines) — but it is argument parsing only. No COFF reader, no PE writer, no .drectve handling, no PDB. Retrofitting COFF into Wild is a from-scratch PE/COFF backend that reuses Wild's parallel resolution/layout architecture, not a port.

---

1. Flag inventory: link.exe vs lld-link vs from-scratch cost

Difficulty rated for a from-scratch linker that must be correct.

Option group	link.exe options	lld-link	Diff	Justification
Response files / driver	@file	✅ (windows + --rsp-quoting=posix)	S	Windows shell tokenization differs from POSIX; lld ships both.
Inputs & library search	/LIBPATH, /DEFAULTLIB, /NODEFAULTLIB[:lib], /WHOLEARCHIVE, %LIB%	✅ all (+/winsysroot, /start-lib, …)	M	Mechanical except the lazy-archive + transitive-.drectve-/DEFAULTLIB fixed point (§2/§3). /NODEFAULTLIB must beat /DEFAULTLIB regardless of discovery order.
Output & image layout	/OUT /DLL /ENTRY /NOENTRY /SUBSYSTEM /MACHINE /BASE /FIXED /ALIGN /FILEALIGN /HEAP /STACK /STUB /VERSION /SECTION /MERGE /ORDER /RELEASE /SWAPRUN /DRIVER /KERNEL /APPCONTAINER	✅ all except /KERNEL (no-op)	M	Header/section emission mechanical. lld hardcodes a default merge table (.idata=.rdata .didat=.rdata .edata=.rdata .xdata=.rdata .00cfg=.rdata .bss=.data, Driver.cpp:2154-2159) — match it or layout diverges from link.exe.
Symbol control	/INCLUDE, /ALTERNATENAME (undocumented), /FORCE, /IGNORE, /WX, /ALIGNCOMM	✅ all (+/includeglob, /wrap, …)	S/M	/ALTERNATENAME is a weak-alias mechanism MSVC headers rely on unconditionally (observed /alternatename:_Avx2WmemEnabled=… in every object including <string>). Not optional.
Exports / imports / DLLs	/EXPORT /DEF /IMPLIB /DELAYLOAD /DELAY:{UNLOAD,NOBIND} /NOEXP	✅ except /delay:, /noexp no-ops	L	§4: implib writing + delay-load thunk synthesis + .edata. lld does not implement /DELAY:UNLOAD/NOBIND semantics.
Debug info	/DEBUG[:FULL|FASTLINK|NONE] /DEBUGTYPE /PDB /PDBALTPATH /PDBSTRIPPED /NATVIS /SOURCELINK /MAP /ILK	✅ except FASTLINK (warns→FULL), SOURCELINK absent, ILK no-op	XL	The single biggest item: MSF + DBI/TPI/IPI/GSI streams + CodeView type merging + /Zi type-server and /Z7 paths. Everything else in this table combined is smaller.
Linker optimization	/OPT:{REF,NOREF,ICF[=n],NOICF,LBR}	✅ REF/ICF (+/opt:safeicf); LBR ignored	M	§6. /OPT:REF = COMDAT-granularity GC, not --gc-sections. Defaults flip with /DEBUG.
LTO / PGO	/LTCG* /GENPROFILE /USEPROFILE /PGD /SPGO…	/LTCG no-op; PGO absent; lld has its own -flto machinery	XL if MSVC-compatible, S if not	MSVC LTCG consumes proprietary IL. Nobody outside Microsoft implements it. Treat as no-op like lld.
Security / mitigations	/DYNAMICBASE /HIGHENTROPYVA /NXCOMPAT /LARGEADDRESSAWARE /TSAWARE /ALLOWBIND /ALLOWISOLATION /INTEGRITYCHECK /GUARD:{CF,EHCONT} /SAFESEH /CETCOMPAT /DEPENDENTLOADFLAG /FUNCTIONPADMIN	✅ nearly all	S for flags, L for /GUARD:CF	Most are one bit in DllCharacteristics; CFG and SAFESEH require table synthesis (§5).
Manifests & resources	/MANIFEST* + .res input	✅; manifest merge via libxml2 or shell-out to mt.exe	M	.res→COFF (cvtres) is in-process in lld (convertResToCOFF).
CLR / managed	/CLR* /ASSEMBLY* /KEYFILE…	❌ absent	XL — do not implement	CLI metadata format "not documented" per PE spec; zero C/C++/Rust builds need it. lld's precedent (shipping Chromium/Firefox) is decisive.
WinRT metadata	/WINMD*	❌ absent	XL — do not implement	C++/CX-era only.
IDL / typelib	/IDLOUT /TLBOUT /TLBID /MIDL /IGNOREIDL	no-ops	S (as no-op)	Accept + ignore.
Incremental	/INCREMENTAL /ILK /MAXILKSIZE	repurposed (import-lib preservation only)	XL (real) / S (deferred)	MVP defers. Note lld never implemented it — the .ilk design is fundamentally at odds with /OPT:REF//OPT:ICF (link.exe itself disables them under /INCREMENTAL).
Diagnostics / repro	/VERBOSE /TIME /LINKREPRO*	mostly ✅	S
ARM64X / hybrid	/MACHINE:ARM64X, /MACHINE:ARM64EC	✅ in lld, actively developed	XL	Skip for x64+ARM64 MVP.
Undocumented-but-real	/Brepro, /TIMESTAMP (lld ext), /GUARDSYM, /THROWINGNEW, /EDITANDCONTINUE, /PDBCOMPRESS …	/Brepro ✅; rest no-ops	S	/Brepro mandatory (§7). /GUARDSYM//THROWINGNEW arrive via .drectve and must at minimum be swallowed.

Bottom line: of ~120 documented options, ~30 are one-bit header writes, ~25 legitimate no-ops, ~20 CLR/WinMD/IDL/PGO to refuse outright (lld's precedent). The residual ~45 are where the work is, and roughly 60% of that work is PDB.

---

2. The .drectve mechanism

What it is (PE/COFF spec): a section named .drectve with IMAGE_SCN_LNK_INFO, containing a text string of linker options (ANSI or UTF-8-with-BOM), removed by the linker after processing, no relocations allowed. lld tokenizes it with Windows shell rules unconditionally and hard-errors on unrecognized directives ("<flag> is not allowed in .drectve").

What's actually allowed inside — Microsoft documents only the #pragma comment(linker,…) whitelist (/DEFAULTLIB /EXPORT /INCLUDE /MANIFESTDEPENDENCY /MERGE /SECTION); the real set is larger. lld's parseDirectives (Driver.cpp:550-670) is the de-facto spec: /EXPORT (bulk fast path, deduped across objects), /INCLUDE (GC root), /EXCLUDE-SYMBOLS, /ALIGNCOMM, /ALTERNATENAME (weak alias), /DEFAULTLIB, /ENTRY, /MERGE, /NODEFAULTLIB, /SECTION, /STACK, /SUBSYSTEM, /RELEASE, /FAILIFMISMATCH, /MANIFESTDEPENDENCY, /ARM64XSAMEADDRESS, plus accepted-and-ignored /EDITANDCONTINUE /GUARDSYM /THROWINGNEW /INFERASANLIBS; anything else errors.

Why this makes /MT-vs-/MD linker-internal. Measured on VS2022 BuildTools (cl /c /EHsc /MD on a TU including <string> with one dllexport), dumpbin /directives:

/FAILIFMISMATCH:annotate_string=0
/FAILIFMISMATCH:annotate_vector=0
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=0
/FAILIFMISMATCH:RuntimeLibrary=MD_DynamicRelease
/DEFAULTLIB:msvcprt
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/alternatename:_Avx2WmemEnabled=_Avx2WmemEnabledWeakValue
/DEFAULTLIB:MSVCRT
/DEFAULTLIB:OLDNAMES
/EXPORT:?foo@@YAHV?$basic_string@...@std@@@Z

Same TU with /MT → RuntimeLibrary=MT_StaticRelease, /DEFAULTLIB:libcpmt, /DEFAULTLIB:LIBCMT. With /MDd → _ITERATOR_DEBUG_LEVEL=2, MDd_DynamicDebug. The CRT choice is never on the linker command line — MSBuild, CMake, and Cargo all rely on the compiler stamping it into every object. Ignore .drectve /DEFAULTLIB → LNK2019 on every CRT symbol. Honor /DEFAULTLIB but not /FAILIFMISMATCH → silently mixed _ITERATOR_DEBUG_LEVEL STL layouts that crash at runtime.

/FAILIFMISMATCH semantics (surface: #pragma detect_mismatch): global map<string,string>; on conflict → fatal LNK2038 naming both files. MS-defined keys: _MSC_VER, _ITERATOR_DEBUG_LEVEL, RuntimeLibrary, _PPLTASKS_WITH_WINRT; values like MT_StaticRelease/MD_DynamicRelease/etc. lld's entire implementation is ~12 lines.

The architectural trap: msvcprt.lib itself carries /FAILIFMISMATCH:RuntimeLibrary=MD_DynamicRelease (verified), so the mismatch map must be updated from directives of archive members pulled in lazily during symbol resolution — resolution and directive processing are mutually recursive. This is a design constraint on any linker whose natural shape is "read all inputs, then resolve" (i.e. Wild's phase pipeline). Difficulty: S (algorithm) / M (plumbing) / L (if the resolution core wasn't designed for it).

---

3. CRT linking: the full /MT vs /MD story

Since VS2015 the CRT is four layers (CRT library features):

Layer	/MT	/MTd	/MD	/MDd
Startup/init (always static)	libcmt	libcmtd	msvcrt	msvcrtd
vcruntime (EH, RTTI)	libvcruntime	libvcruntimed	vcruntime→vcruntime.dll	vcruntimed
Universal CRT	libucrt	libucrtd	ucrt→ucrtbase.dll	ucrtd→ucrtbased.dll
C++ stdlib	libcpmt	libcpmtd	msvcprt→msvcp.dll	msvcprtd

How the choice propagates — measured, not inferred. The compiler emits only the top two layers into .drectve; the rest arrive transitively from the libraries' own .drectve records:

$ dumpbin /directives msvcrt.lib | findstr /I DEFAULTLIB | sort /unique
   /defaultlib:kernel32.lib  /defaultlib:msvcrt.lib  /defaultlib:ucrt.lib  /defaultlib:vcruntime.lib
$ dumpbin /directives libcmt.lib | …
   /defaultlib:kernel32.lib  /defaultlib:libcmt.lib  /defaultlib:libucrt.lib  /defaultlib:libvcruntime.lib

So /DEFAULTLIB resolution is a worklist to fixed point, with self-references, requiring case-insensitive canonicalized dedup (MSVCRT from the compiler vs msvcrt.lib from the library; lld lowercases for /nodefaultlib). /DEFAULTLIB:OLDNAMES (POSIX aliases) is always present and must resolve.

/NODEFAULTLIB precedence (docs): explicit libs → /DEFAULTLIB libs → obj-embedded defaultlibs; /NODEFAULTLIB:x overrides /DEFAULTLIB:x; bare /NODEFAULTLIB suppresses all (how #[no_std]/custom-CRT builds work).

Failure modes: (1) detected — LNK2038 via /FAILIFMISMATCH; (2) undetected — both libcmt and msvcrt on the list → LNK4098 + LNK2005 duplicate-symbol shower (a from-scratch linker gets the duplicates for free but won't emit LNK4098 unless it models conflicting CRT sets — lld doesn't either); (3) runtime-only — cross-DLL CRT state, undetectable by any linker.

Cost: M. ~300 lines. The risk is entirely in where it sits in the pipeline.

---

4. Import/export machinery

Import libraries: short vs long format

Both live in a standard !<arch> archive with first/second linker members (spec §7; note the second member is little-endian + sorted, the first big-endian — both must be written correctly for lib.exe interop). Long format member = a real COFF object. Short format (spec §8) = 20-byte import header (Sig1=IMAGE_FILE_MACHINE_UNKNOWN, Sig2=0xFFFF, Type: CODE/DATA/CONST, NameType: ORDINAL/NAME/NAME_NOPREFIX/NAME_UNDECORATE) + two strings — "sufficient information to accurately reconstruct the entire contents of the member." The linker synthesizes the .idata contributions and __imp_<name> from 20 bytes + 2 strings. Difficulty: M (~500 lines read+write; subtlety is x86 name-type handling _foo@8 ↔ foo).

__imp_ and thunk synthesis

dllimport calls go indirect via __imp_<name>; calls without dllimport leave a direct call foo, and the linker synthesizes foo: jmp [__imp_foo]. Data imports without dllimport are not fixable on MSVC. Difficulty: S (a few arch-specific byte arrays).

/DELAYLOAD

Linker rewrites IAT slots to per-import thunks tail-calling a per-DLL stub → __delayLoadHelper2 (delayimp.lib) → LoadLibrary/GetProcAddress → patch. Structures: Delay-Load Directory Table, dlattrRva form. lld's DLL.cpp shows the real cost: hand-encoded thunks × 4 architectures, __imp___load_<name> synthetics for CFG's .giats, and synthetic .pdata/.xdata for the generated thunks on x64. Inherited constraints: no data imports, no delay-loading kernel32, no binding of forwarders. Difficulty: M/L (~1000 fiddly lines).

Export table generation

Four input paths that must converge: (1) dllexport → compiler emits /EXPORT:<decorated> into .drectve; (2) .def EXPORTS (with forwarders other.sym, ordinal forwarders other.#42, @ordinal, NONAME, PRIVATE, DATA); (3) /EXPORT: on the command line; (4) #pragma comment(linker,"/export:…"). Output is the five-table .edata (name pointer table sorted ascending — the loader binary-searches). Undecorated→decorated fuzzy matching is a documented linker responsibility. lld's .def support is partial (EXPORTS, HEAPSIZE, STACKSIZE, NAME, VERSION only). Difficulty: M — layout trivial, matching rules are where compat bugs live.

MinGW: .dll.a, auto-import, pseudo-relocs

Per binutils ld WIN32 docs: -lxxx searches 8 forms including direct linking against a .dll with no import library. Auto-export-everything by default (disabled by .def/dllexport, re-enabled --export-all-symbols). Auto-import rewrites data references into IAT indirections; non-zero addends are impossible statically → runtime pseudo-relocations: the linker emits an (IAT-slot RVA, target RVA, size) table between __RUNTIME_PSEUDO_RELOC_LIST__/__RUNTIME_PSEUDO_RELOC_LIST_END__ and the CRT's _pei386_runtime_relocator fixes them at startup (lld Writer.cpp:2419-2467; runtime side in mingw-w64-crt pseudo-reloc.c). Additional MinGW-persona obligations in lld: different default merge table (.ctors=.rdata etc.), __CTOR_LIST__/__DTOR_LIST__ sentinels, --kill-at, stdcall fixup, --out-implib, --output-def, different decoration predicate.

Honest assessment: import/export is ~70% mechanical, ~30% genuinely tricky — concentrated in (a) undecorated↔decorated matching, (b) delay-load thunks + unwind, (c) auto-import/pseudo-reloc (a whole parallel relocation model).

---

5. Windows-specific sections/metadata the linker must synthesize

Item	Who does what	Difficulty
.reloc base relocations	100% linker. Blocks per 4 KB page, 4-bit type + 12-bit offset; HIGHLOW/DIR64/ARM64 forms; suppressed by /FIXED.	S — simpler than ELF dynamic relocs
x64 .pdata/.xdata	Linker's jobs: (1) sort .pdata by function address (spec requirement); (2) synthesize unwind for linker-generated code (delay-load & range thunks); (3) COMDAT-associative discard propagation so a GC'd function's .pdata dies with it.	S sort, M synthesized unwind
/SAFESEH (x86-32 only)	Collect .sxdata symbol indices + @feat.00 LSB, dedupe/sort, emit RVA table into load config. If any object lacks @feat.00 the image silently loses the table.	M, skippable for x64+ARM64 MVP
/GUARD:CF	The heaviest mitigation. Collect .gfids$y/.gljmp$y/.giats$y/.gehcont$y, skip entries whose section was GC'd (subtle), map .giats to delay-load thunks, build sorted RVA tables in .00cfg, patch GuardCFFunctionTable/Count, GuardFlags (with the 4-bit stride subfield), GuardCFCheckFunctionPointer, set IMAGE_DLLCHARACTERISTICS_GUARD_CF.	L
Load config directory	Linker does not create it — the CRT provides _load_config_used and the linker patches fields in place + sets the data directory (lld prepareLoadConfig). "Patch a CRT-provided struct" has no ELF analogue.	M
TLS directory	Locate magic _tls_used symbol (spec-mandated technique), set TLS data directory, $-sort .tls$ contributions, fix the alignment field. Raw Data Start/End are VAs → need base relocations.	M
Resources (.rsrc from .res)	Do cvtres's job in-process: parse .res, build the 3-level Type→Name→Language binary-sorted tree.	M
Manifest embedding	Default-manifest XML generation + merging /MANIFESTINPUT (lld: libxml2 or shell out to mt.exe), wrap as RT_MANIFEST resource.	M
Rich header	link.exe writes it; lld-link does not emit one and ships Chromium/Firefox fine → empirically skippable. (Unverified speculation: some AV heuristics score on its presence.)	S (skip)
Authenticode	Nothing at link time; just keep cert table + debug data at end-of-file per spec so signtool can append.	S
/DEPENDENTLOADFLAG, /CETCOMPAT	Load-config field writes / DllCharacteristicsEx bit. /CETCOMPAT forces a debug directory to exist.	S
PDB + debug directory	IMAGE_DEBUG_TYPE_CODEVIEW (GUID+Age+path), optional IMAGE_DEBUG_TYPE_REPRO; the PDB itself: MSF container, DBI/TPI/IPI/GSI/PSI streams, CodeView type merging across .debug$T.	XL — dominates the schedule

---

6. COMDAT / section semantics — how much ELF layout logic transfers

COMDAT selection: 6 kinds vs ELF's 1

PE spec: NODUPLICATES(error on dup), ANY(keep one), SAME_SIZE(error if sizes differ), EXACT_MATCH(error if contents differ), ASSOCIATIVE(linked iff the parent COMDAT is linked; per-section back-pointer DAG, cycle-checked), LARGEST(keep largest). ELF SHT_GROUP has only "same signature → keep one."

Delta for an ELF linker: ANY transfers; ASSOCIATIVE is group membership inverted (.pdata/.xdata/.gfids/.debug$S all associative to their .text$mn — get it wrong and unwind info survives a GC'd function); LARGEST/SAME_SIZE/EXACT_MATCH/NODUPLICATES have no ELF analogue (LARGEST is used by MSVC for selectany data and vftables).

String/constant merging

COFF has no SHF_MERGE. MSVC puts each string literal in its own SELECT_ANY COMDAT .rdata section named by content hash (??_C@…). Consequences: ELF string-merge machinery is dead weight for COFF; dedup falls out of COMDAT resolution + /OPT:ICF (which folds read-only data too and is on by default on Windows). Net: COFF has more input sections but simpler per-section semantics.

/OPT:REF vs --gc-sections

Not equivalent. /OPT:REF is on by default and operates at COMDAT granularity only — lld's markLive seeds the worklist with every non-COMDAT chunk ("COMDAT section chunks are dead by default. Add non-COMDAT chunks"), so an object compiled without /Gy is one indivisible .text. The GC core transfers; the seeding rule and default-on-ness must change, and /INCLUDE becomes a first-class root source from .drectve.

/OPT:ICF

Same algorithm as ELF ICF (lld's comment says so), but: default-on for COFF; must respect COMDAT associativity (assocEquals); /OPT:ICF=n iterations; /opt:safeicf extension.

Layout

• $-suffix ordering (spec, Grouped Sections): contributions sorted lexically by the part after $, then $ and suffix discarded. This is how .CRT$XCA…XCZ static-init ordering and .gfids$y aggregation work. No ELF analogue; must be exact or C++ static init breaks.
• SectionAlignment (default 4096) vs FileAlignment (default 512) independent knobs.
• No PT_LOAD segments — the ELF "assign sections to segments by permission" pass becomes "merge sections by name per the merge table"; permissions are per-section characteristics.

Verdict: the skeleton (parallel parse, symbol table, GC, ICF, address assignment, parallel relocation, output write) transfers well — exactly Wild's strength. The semantics layer (COMDAT kinds, associativity, $ ordering, .drectve, merge tables, no SHF_MERGE) is substantially all-new. Rough split: ~50% of layout code reusable in shape, ~15% verbatim.

---

7. Determinism on Windows

What /Brepro actually does

Undocumented by Microsoft; lld's implementation is the readable spec (Writer::writeBuildId): xxh3 the output buffer; low 32 bits → COFF header TimeDateStamp + debug-directory timestamps; PDB70 record gets Age=1 + 8 hash bytes + "LLD PDB."; plus an empty IMAGE_DEBUG_TYPE_REPRO entry marking "timestamp is a hash." Image-level determinism is ~6 lines. /TIMESTAMP:n (lld extension) is the escape hatch for tools wanting a plausible date.

Full checklist for byte-reproducible EXE/DLL + PDB

Nondeterminism source	Fix	Owner
COFF header + debug directory TimeDateStamp	/Brepro or /TIMESTAMP:	linker
PDB GUID/Signature/Age	derive from content hash	linker
Absolute PDB path in image	/PDBALTPATH:%_PDB%	linker
Absolute source paths in PDB	/pdbsourcepath: + controlled build dir	linker + build
IMAGE_EXPORT_DIRECTORY.TimeDateStamp	write 0	linker
IMAGE_RESOURCE_DIRECTORY.TimeDateStamp	write 0	linker
Import library archive Date fields + short-import timestamps	write 0/blank	linker (/IMPLIB writer)
.obj timestamps	clang-cl /Brepro	compiler
__DATE__/__TIME__	-D…= -Wno-builtin-macro-redefined	compiler
/INCREMENTAL	must be off (intentionally different outputs each build)	build config
Multithreaded ordering	stable sorts, deterministic worklists	linker

The ducible post-processor exists because link.exe leaves several of these nondeterministic; a from-scratch linker should just get them right. Caveat from that post: the PDB DBI header carries the toolchain build number, so cross-machine PDB reproducibility additionally requires identical toolchain versions.

Does the MSVC ecosystem tolerate it?

Empirically yes: Chromium and Firefox ship lld-link-built /Brepro binaries in production (exercising WinDbg, crash reporting, symbol servers daily); rustc 1.69+ passes /Brepro when SOURCE_DATE_EPOCH is set; debuggers/symbol servers key on PDB GUID+Age, not timestamp. One documented failure mode: tools parsing the timestamp as a date (Win7 app-compat DB) — mitigate with /timestamp:. (SymSrv indexing of binaries by TimeDateStamp+SizeOfImage still works with hashed timestamps, but no primary source guarantees it — unverified.)

Difficulty: S. Determinism is the cheapest requirement on the list and should be the default mode, not a flag.

---

Implementation-scale reference point

lld/COFF is 37 files, ~752 KB: Writer.cpp 114 KB, Driver.cpp 106 KB, PDB.cpp 69 KB, InputFiles.cpp 58 KB, SymbolTable.cpp 51 KB, Chunks.cpp 47 KB, DebugTypes.cpp 46 KB, DLL.cpp 39 KB — plus llvm/Object/COFF*, llvm/DebugInfo/{MSF,CodeView,PDB}, llvm/Object/WindowsResource, llvm/WindowsManifest, and the tablegen option parser. That is the size of exactly the stated reld scope ("full link.exe compatibility minus /INCREMENTAL, minus CLR/WinMD/MIDL/PGO/FASTLINK"). Any from-scratch estimate should anchor to that number — with the caveat that ~25% of it (PDB + CodeView type merging) is a self-contained subsystem that could in principle be linked against LLVM rather than reimplemented.

[zackees]

Adversarial synthesis + DECISION

Fable's cross-examination of the five research reports above, followed by the decision. 2026-08-26.

What the evidence actually says (cross-checked across all five reports)

1. The LTO question is settled: linker choice is irrelevant for LTO builds. The 17–25x allocator swings (38m47s → 2m15s linking clang.exe by changing malloc alone) and the 96%-idle ThinLTO trace prove LTO wall time is LLVM codegen + allocator behavior inside the linker process, not link mechanics. Wild's own benchmark confirms from the other side: wild-lto loses to mold and lld. Consequence: the decision must be driven entirely by the non-LTO dev loop, and the LTO deliverable is allocator + DTLTO + caching work, which lives naturally in the LLVM/lld world.

2. On Windows debug links, the linker IS the PDB writer. 96.8% of an 81.9s link is PDB emission. Every fast-linker project in history has either taken years on PDB (LLVM: ~3 years with Microsoft's source dump; Epic radlink: ~2 years in, still alpha), deferred it indefinitely (Zig: 8 years, still a TODO comment; the Wild COFF port explicitly excludes it), or refused the format entirely (mold). Wild's entire speed advantage is on the object-graph side — the part that is under 3% of a Windows debug link.

3. The user constraint "full link.exe compatibility mandatory (except /INCREMENTAL)" is the decisive constraint. lld-link is that compatibility surface today, shipping Chromium and Firefox, including PDB, both MSVC and MinGW personas, .drectve, CRT defaultlib fixed-point, CFG, delay-load, ARM64EC. The Wild path has 759 lines of argument parsing and none of the rest; the honest estimate assembled from Zig/radlink/Mach-O-port calibration is 1–2 engineer-years to MSVC-parity linking without PDB, plus the PDB discontinuity on top. That is not an MVP-cycle deliverable under this constraint.

4. The byte-identity test oracle — the reason to prefer the lld path — is confirmed real, with a documented recipe. /Brepro /pdbaltpath:%_PDB% /pdbsourcepath:<fixed>, same argv[0] path, same cwd, pinned LLVM version. The three traps (EnvBlockSym recording exe/cmd/cwd, default absolute pdbaltpath, wall-clock timestamp default) are all controllable. Parallel type merging and ICF are deterministic by construction. On the Wild path this oracle is impossible by construction and the replacement apparatus (a COFF linker-diff + test corpus) is ~10k LOC + 221 test dirs of work that doesn't exist.

5. The headroom for an lld-COFF fork is real and localized. Best modern datapoint: a 26 GB Unreal link burns 259.9s CPU in 29.7s wall on 64 threads — ~8.8x average concurrency, ~25s effectively serial. The serial points are enumerated and small in number: input-file taskQueue (fully serial), PDB symbol merging (serial; flagged as the obvious next step by upstream in 2020 and untouched for 6 years), TPI/IPI stream layout, MSF disk commit. Plus the parse-speed gap (lld 320ms vs wild 120ms on the same inputs). A 1.5–3x non-LTO win is a defensible target; the first candidate (parallel PDB symbol merging) is even upstreamable.

6. Both flavors come nearly free on the lld path, and are expensive on the Wild path. lld's MinGW driver is a ~700-line argument translator over the same COFF core; rustc integration is stable -Clinker= on msvc (name the binary anything but lld-link) and -Clinker-flavor=ld on gnu. On the Wild path, MinGW auto-import/pseudo-relocs, both import-library styles, and direct-DLL linking are net-new backend work — and Wild's MSVC flavor has no maintainer champion ("MSVC doesn't matter to me").

Adversarial findings — the strongest case AGAINST the recommendation, stated fairly

• The headroom may be smaller than it looks. Ganea's 2019 datapoint had lld-link 9.0 slower than VS2019 link.exe on a AAA workload, and Microsoft closed a 3–6x gap by pure data-structure work; VS2026 removed /DEBUG:FASTLINK because FULL got fast enough. There is no rigorous 2024–2026 lld-link vs link.exe benchmark anywhere — we would be investing ahead of a baseline we haven't measured. Mitigation: the benchmark suite is work item Position reld as a wild successor; add test, stress, and benchmark infrastructure #1 and doubles as the missing evidence for Use lld by default on x64 msvc windows rust-lang/rust#71520.
• A fork's PDB hot path lives in llvm/lib/DebugInfo/PDB/, not in lld — a serious PDB-speed fork forks LLVM too, or upstreams. Budget for that.
• The Wild ceiling is genuinely higher long-term — 2x over mold, 3–9x over lld on ELF, and the incremental-linking future is Wild's stated end-goal, which lld will likely never have. Rejecting Wild this cycle is not a judgment that Wild-COFF is a bad idea forever; the upstream port (wild#2320/#2374) is already moving and the object crate + ms-pdb make the starting position better than Mach-O's was.
• Wild's published margins are tmpfs-only and its gains have flattened ("Not much changed in terms of performance", 0.10.0); on NTFS + Defender + PDB the margin on Windows is unproven and plausibly much smaller. This cuts against Wild, not for it — noting it here because it means even the Wild ceiling on Windows is speculative.
• Fork maintenance risk on the Wild side is severe (~120 commits/month, 13/month on the exact trait surface; hard fork economically insane, upstream-only viable) versus mild on the lld side (~5–10 COFF commits/month, none touching the hot path).

Open questions carried forward (tracked, not blocking)

1. A1 baseline: profile reld's actual Windows workloads (lld-link /time + --time-trace) — where does OUR time go: PDB type merge vs symbol merge vs input parse? Decides optimization order.
2. ms-pdb capability check: can microsoft/pdb-rs construct a linker-grade PDB from scratch (full TPI/IPI merge, GSI/PSI, line info)? If yes, the future Wild-COFF cost collapses from years to months. Cheap spike; do it once, file the answer here.
3. E3 reproducibility-as-product: is byte-for-byte determinism a reld product requirement (content-addressed caching) or only the test oracle? Either way lld satisfies it; if product, it further locks in this decision.
4. lld MinGW gaps to verify when we get there: CFGuard flags not mapped in the MinGW driver; delay-load tailMergeX64 unwind gap (#59639); partial .def support.

---

DECISION

Chosen: Option 1 — fork LLD's COFF driver (plus the needed llvm/DebugInfo/PDB bits) and optimize it, hybrid-style: fork for velocity, upstream the clean wins.

Rejected for this cycle: Option 2 (Wild retrofit) — not on performance ceiling, but on (a) the mandatory full-link.exe-compat constraint, which only lld already satisfies; (b) the PDB discontinuity, which has defeated or been deferred by every fast-linker project except Epic's ~2-year effort; (c) the missing test oracle; (d) fork-economics against a 120-commit/month moving abstraction. Revisit trigger: the upstream Wild COFF port reaches "links real MSVC programs" AND the ms-pdb spike (question 2) comes back positive.

Plan sketch:

1. Benchmark suite first (fills question 1 and the rust#71520 gap): lld-link vs link.exe vs our fork, msvc + gnu, debug/release, PDB on/off, real projects. This is also the regression harness.
2. Fork setup: LLD_BUILT_STANDALONE against pinned LLVM; binary named NOT lld-link (clean rustc integration via stable -Clinker=); determinism-by-default (/Brepro-equivalent + %_PDB% + fixed pdbsourcepath) as the fork's default mode.
3. Byte-identity oracle in CI from day one: every optimization must produce byte-identical EXE+PDB vs the unoptimized fork (same argv[0]/cwd recipe as documented in phase-1 report).
4. Optimization order (pending Position reld as a wild successor; add test, stress, and benchmark infrastructure #1's profile): parallel PDB symbol merging (upstreamable, flagged by upstream since 2020) → parallelize input parsing/taskQueue → GHASH-by-default + allocator (rpmalloc/mimalloc) → TPI layout + MSF commit overlap → DTLTO/caching for the LTO story.
5. MVP scope: x64 msvc + gnu flavors, everything lld-link supports today, /INCREMENTAL explicitly out (matching lld's own stance).

Kill criteria (written before build starts, per the no-rabbit-hole rule):

• If the phase-1 benchmark shows lld-link (tuned flags, rpmalloc, /threads) is already within ~15% of link.exe and the profile shows <25% headroom on our workloads, stop and ship "adopt stock lld-link + flags" instead of a fork.
• If byte-identity cannot be held for an optimization class after the documented recipe, that optimization ships behind a flag or dies — the oracle is not negotiable.
• Re-evaluate the whole track if Microsoft ships a step-change linker (the rui314 risk) or if Wild-COFF + ms-pdb both mature (the revisit trigger above).

🤖 Generated with Claude Code

[zackees]

Follow-on implementation is tracked in #92.

It sequences the selected LLD-COFF strategy as follows:

1. First replace the Linux reld/Wild executable's default system allocator with a pinned, vendored zackees/mimalloc-pprof integration; establish system vs MI_PPROF=OFF vs sampled-profiling measurements while preserving byte-identical linker artifacts and native execution.
2. Create zackees/llvm-ld as a minimal C/C++ library-only fork/extraction of the current LLD COFF driver (MSVC + MinGW). It will own the pinned LLVM source, narrow C ABI, vendored allocator replacement, and manual upstream LLD imports.
3. Keep Rust out of llvm-ld: reld will own the Rust wrapper and vendor the pinned C/C++ source below _vendor/ through a git-backed import, not crates.io.
4. First Windows milestone: demonstrate mimalloc-pprof works unchanged in the isolated COFF library, then compare EXE + PDB byte-for-byte with the pinned unmodified LLD baseline under fixed args/path/cwd/determinism settings, followed by native MSVC and MinGW execution. Only then measure allocator gains and prioritize linker optimizations.

Research note: mun-lang/lld-rs is useful prior art but not the base: it is LLVM-14-era, links every LLD driver, and its docs.rs build fails. Current LLD's COFF-as-a-library API plus a small C ABI shim is the lower-maintenance base.