Expose a JITLink object-linking-layer creator via libLLVMSharp

[tannergooding]

Summary

The Kaleidoscope tutorial JIT (samples/KaleidoscopeTutorial/Kaleidoscope.Common/KaleidoscopeJit.cs) intermittently aborts on Windows x64 with:

LLVM ERROR: IMAGE_REL_AMD64_ADDR32NB relocation requires an ordered section layout

Root cause: an ORC LLJIT created with a null builder defaults to RtDyldObjectLinkingLayer (RuntimeDyld) on x86_64/COFF, and RuntimeDyldCOFFX86_64 fatally aborts when the image-base-relative IMAGE_REL_AMD64_ADDR32NB relocations in a function's .pdata/.xdata unwind info cannot encode. Whether they encode depends on where the default SectionMemoryManager's separately-mmap'd sections land, which is ASLR-dependent — hence intermittent.

The correct fix is to run the object-linking layer on JITLink, whose COFF/x86-64 backend does not impose the ordered-section-layout constraint.

The gap

The LLVM-C API (libLLVM 21.1.8) exposes only RTDyld object-linking-layer creators:

• LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager
• LLVMOrcCreateRTDyldObjectLinkingLayerWithMCJITMemoryManagerLikeCallbacks

There is no C function that constructs a JITLink ObjectLinkingLayer (it is a C++-only class), so LLVMOrcLLJITBuilderSetObjectLinkingLayerCreator has no JITLink layer to return. The generated bindings already consume the full llvm-c/Orc.h, OrcEE.h, LLJIT.h, LLJITUtils.h set, so this is genuinely absent from the C surface rather than a generator omission.

Request

Expose a JITLink object-linking-layer creator through the libLLVMSharp native helper (which exists precisely to fill such C-API gaps) and surface it through the interop — e.g. a helper returning an LLVMOrcObjectLayerRef backed by llvm::orc::ObjectLinkingLayer + a JITLink in-process memory manager, usable from LLVMOrcLLJITBuilderSetObjectLinkingLayerCreator.

Workaround in place

Until then, the Kaleidoscope sample keeps RtDyld but installs a custom MCJIT-like memory manager that allocates every object's sections from a single contiguous slab, so getImageBase() equals the slab base and the ADDR32NB range check always holds. Once a JITLink creator is available, the sample should drop that workaround and force JITLink instead.

[tannergooding]

Additional evidence from investigating the intermittent Kaleidoscope IMAGE_REL_AMD64_ADDR32NB failure (the sample-side workaround this issue would unblock):

Confirmed against llvmorg-21.1.8 sources that no pinned LLVM-C entry point can fix this from the sample:

• LLJIT.cpp prepareForConstruction sets UseJITLink = !TT.isOSBinFormatCOFF() for x86_64/aarch64, so on Windows x64 (COFF) the default object-linking layer is always RTDyldObjectLinkingLayer + SectionMemoryManager. JITLink is never selected on COFF.
• To force JITLink you must construct orc::ObjectLinkingLayer(ES) directly (C++-only). OrcV2CBindings.cpp exposes only RtDyld creators (LLVMOrcCreateRTDyldObjectLinkingLayerWith{SectionMemoryManager,MCJITMemoryManagerLikeCallbacks}); there is no C constructor for ObjectLinkingLayer.
• Worse, the custom object-linking-layer creator path in LLJIT::createObjectLinkingLayer is mutually exclusive with LLJIT's COFF fixups: when a creator is supplied LLJIT skips setOverrideObjectFlagsWithResponsibilityFlags(true) + setAutoClaimResponsibilityForObjectSymbols(true). Both C-API RtDyld creators also omit those. So any sample-built RtDyld layer regresses COFF constant-pool symbol resolution (Failed to materialize symbols: { __real@... }) even before the ADDR32NB issue is reached — reproduced locally.

Net: the sample cannot avoid RtDyld-on-COFF with the current bindings. A libLLVMSharp helper that constructs a JITLink ObjectLinkingLayer (returning an LLVMOrcObjectLayerRef usable with LLVMOrcLLJITBuilderSetObjectLinkingLayerCreator) is the correct fix; a secondary option is exposing setters for the two COFF responsibility flags on the RtDyld layer.