Repository navigation
--jit-native: say why it still links the static default library - #631
Merged
Merged
Conversation
#630 made --emit=dll read the default library's data through `__imp_`, but that does not carry over to --jit-native. Its DLL links the JIT cache's objects, which are compiled for the JIT's static large code model, and x86 codegen gives a dllimport global no `__imp_` reference under that model (X86Subtarget::classifyGlobalReference). Checked: with the data marked dllimport for JIT objects too, the in-memory JIT still runs, but the objects keep plain `Math.PI` references and the DLL link fails without the static default library. The comment and the design doc said this was the same bug as --emit=dll; they now give the actual reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
This changes a comment and a doc only, with no code change. The
request.staticDefaultLib = truecomment intslang/tslang/jitnative.cppand the "As built" section oftslang/docs/jit-native-dll-debugging-design.mdsaid--jit-nativelinks the static default library because of "the same failure as--emit=dll", and called that a separate bug. #630 fixed that--emit=dllfailure, so this PR states the actual reason the static default library is still needed.Why the #630 fix doesn't apply to --jit-native
The
--jit-nativeDLL links the JIT cache's objects, and those objects are compiled with the JIT's target machine.JITTargetMachineBuilder::detectHostleaves the code model at its default. On x86-64 that default is the large code model with a static relocation model. Under that combinationX86Subtarget::classifyGlobalReferencereturnsMO_NO_FLAGbefore it ever looks atdllimport, so a dllimport global gets no__imp_reference.I checked this on
mainwith the Map /Math.PI/Number.EPSILON/instanceof RangeErrorrepro:staticDefaultLib: the DLL link fails with LNK2019 onPrimeHelpers.hashCollisionThreshold,Math.PI,Number.EPSILONandRangeError..rtti.importfor JIT objects (A shared library reads the default library's data through its DLL #630's gate widened toisJit): ExportFixPass does set those globals todllimport(section=import, MSVC triple). The in-memory JIT still runs correctly. But the cached object still hasU Math.PIand no__imp_symbols, and the link fails the same way.So linking the static default library is still the right choice for
--jit-native. Making the DLL import its data would need the JIT objects compiled with a different code model, which also changes the in-memory JIT.🤖 Generated with Claude Code