[all-commits] [llvm/llvm-project] 7260cd: [ORC][COFF] Introduce COFFVCRuntimeBootstrapper.

[Sunho Kim via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7260cdd2e13a3a8970fe106c3d705609029640b5
      https://github.com/llvm/llvm-project/commit/7260cdd2e13a3a8970fe106c3d705609029640b5
  Author: Sunho Kim <ksunhokim123 at gmail.com>
  Date:   2022-08-11 (Thu, 11 Aug 2022)

  Changed paths:
    A llvm/include/llvm/ExecutionEngine/Orc/COFFVCRuntimeSupport.h
    M llvm/include/llvm/ExecutionEngine/Orc/ExecutorProcessControl.h
    M llvm/include/llvm/ExecutionEngine/Orc/Shared/OrcRTBridge.h
    M llvm/include/llvm/ExecutionEngine/Orc/SimpleRemoteEPC.h
    M llvm/include/llvm/ExecutionEngine/Orc/TargetProcess/TargetExecutionUtils.h
    M llvm/lib/ExecutionEngine/Orc/CMakeLists.txt
    A llvm/lib/ExecutionEngine/Orc/COFFVCRuntimeSupport.cpp
    M llvm/lib/ExecutionEngine/Orc/ExecutorProcessControl.cpp
    M llvm/lib/ExecutionEngine/Orc/Shared/OrcRTBridge.cpp
    M llvm/lib/ExecutionEngine/Orc/SimpleRemoteEPC.cpp
    M llvm/lib/ExecutionEngine/Orc/TargetProcess/OrcRTBootstrap.cpp
    M llvm/lib/ExecutionEngine/Orc/TargetProcess/TargetExecutionUtils.cpp

  Log Message:
  -----------
  [ORC][COFF] Introduce COFFVCRuntimeBootstrapper.

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 crt 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 complication 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.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D130456