[PATCH] D130456: [ORC][COFF] Introduce COFFVCRuntimeBootstrapper.

[Sunho Kim via Phabricator via llvm-commits]

sunho created this revision.
sunho added reviewers: lhames, sgraenitz.
Herald added subscribers: StephenFan, hiraditya, mgorny.
Herald added a project: All.
sunho requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Introduces COFFVCRuntimeBootstrapper that loads/initialize vc runtime libraries. In COFF, we *must* jit-link vc runtime libraries as COFF relocation types have no proper way to deal with out-of-reach data symbols ragardless of linking mode. (even dynamic version msvcrt.lib have tons of static data symbols that must be jit-linked) This class tries to load vc runtime library files from msvc installations with an option to override the path.

There are some complications when dealing with static version of vc runtimes. First, they need static initializers to be ran that requires COFFPlatform support but orc runtime will not be usable before vc runtimes are fully initialized. (as orc runtime will use msvc stl libraries) COFFPlatform that will be introduced in a following up patch will collect static initializers and run them manually in host before boostrapping itself. So, the user will have to do the following.

1. Create COFFPlatform that addes static initializer collecting passes.
2. LoadVCRuntime
3. InitializeVCRuntime
4. COFFPlatform.bootstrap()

Second, the internal initialization function had to be reimplemented in orc side. There are other ways of doing this, but this is the simplest implementation that makes platform fully responsible for static initializer. The comlication comes from the fact that crt initialization functions (such as acrt_initialize or dllmain_crt_process_attach) actually run all static initializers by traversing from __xi_a symbol to __xi_z. This requires symbols to be contiguously allocated in sections alphabetically sorted in memory, which is not possible right now and not practical in jit setting. We might ignore emission of __xi_a and __xi_z symbol and allocate them ourselves, but we have to take extra care after orc runtime boostrap has been done -- as that point orc runtime should be the one running the static initializers.


https://reviews.llvm.org/D130456

Files:
  llvm/include/llvm/ExecutionEngine/Orc/COFFVCRuntimeSupport.h
  llvm/include/llvm/ExecutionEngine/Orc/ExecutorProcessControl.h
  llvm/lib/ExecutionEngine/Orc/CMakeLists.txt
  llvm/lib/ExecutionEngine/Orc/COFFVCRuntimeSupport.cpp
  llvm/lib/ExecutionEngine/Orc/ExecutorProcessControl.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D130456.447182.patch
Type: text/x-patch
Size: 13839 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220725/27521b82/attachment.bin>