This is an archive of the discontinued LLVM Phabricator instance.

[ORC_RT][COFF] Initial platform support for COFF/x86_64.
AcceptedPublic

Authored by sunho on Jul 25 2022, 6:12 AM.

Details

Summary

Initial platform support for COFF/x86_64.

Completed features:

  • Statically linked orc runtime.
  • Full linking/initialization of static/dynamic vc runtimes and microsoft stl libraries.
  • SEH exception handling.
  • Full static initializers support
  • dlfns
  • JIT side symbol lookup/dispatch

Things to note:

  • It uses vc runtime libraries found in vc toolchain installations.
  • Bootstrapping state is separated because when statically linking orc runtime it needs microsoft stl functions to initialize the orc runtime, but static initializers need to be ran in order to fully initialize stl libraries.
  • Process symbols can't be used blidnly on msvc platform; otherwise duplicate definition error gets generated. If process symbols are used, it's destined to get out-of-reach error at some point.
  • Atexit currently not handled -- will be handled in the follow-up patches.

Diff Detail

Event Timeline

sunho created this revision.Jul 25 2022, 6:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2022, 6:12 AM
sunho requested review of this revision.Jul 25 2022, 6:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2022, 6:12 AM
sunho updated this revision to Diff 447302.Jul 25 2022, 6:17 AM
sunho updated this revision to Diff 447311.Jul 25 2022, 6:51 AM

rebase.

sunho updated this revision to Diff 448832.Jul 30 2022, 7:38 PM
lygstate added inline comments.
compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
87

idnent set please

sunho retitled this revision from [ORC][ORC_RT][COFF] Initial platform support for COFF/x86_64. to [ORC_RT][COFF] Initial platform support for COFF/x86_64..Jul 31 2022, 2:34 PM
sunho updated this revision to Diff 449201.Aug 2 2022, 12:34 AM

Support static initializer loop that JITs init symbols on demand like Macho platform with many polishing.

sunho edited the summary of this revision. (Show Details)Aug 2 2022, 12:34 AM
sunho updated this revision to Diff 449211.Aug 2 2022, 1:07 AM

Add some locks for thread safety.

sunho updated this revision to Diff 449245.Aug 2 2022, 3:32 AM
sunho updated this revision to Diff 449246.
sunho updated this revision to Diff 449278.Aug 2 2022, 6:25 AM

rebase.

sunho updated this revision to Diff 449287.Aug 2 2022, 7:25 AM

Add more tests.

sunho updated this revision to Diff 449288.Aug 2 2022, 7:30 AM
sunho updated this revision to Diff 449504.Aug 2 2022, 6:00 PM

Make COFFPlatform responsible for vc runtime setup.

sunho updated this revision to Diff 449515.Aug 2 2022, 7:40 PM

Proper support of multiple jitdylibs.

sunho updated this revision to Diff 449516.Aug 2 2022, 7:43 PM
lhames added a comment.Aug 7 2022, 6:12 PM

Thanks for your patience with the review @sunho!

This is great stuff -- I'm very excited to see these features coming to Windows.

compiler-rt/lib/orc/CMakeLists.txt
3–10

What's the distinction between ORC_COMMON_SOURCES sources and ORC_ALL_SOURCES?

looks like dlfcn_wrapper.cpp is included in both? Was that intentional?

It looks like the other edits to CMakeLists.txt include cleanup that's tangential to COFF support. How hard would it be to break out this cleanup from the rest of the patch? (Definitely nice to see this being cleaned up either way!)

compiler-rt/lib/orc/adt.h
90–127 ↗(On Diff #449516)

These are nice extensions, but the switch to c++17 in https://github.com/llvm/llvm-project/commit/b1356504e63ae821cccf1e051a0d2526bdfef2b0 means that we can now drop __orc_rt::string_view entirely in favor of std::string_view. I will land a patch for that tomorrow.

compiler-rt/lib/orc/coff_platform.cpp
59

Where did the Xtor prefix come from? I really like that. Much cleaner than CtorDtor.

537

Is the explicit this-> necessary here?

compiler-rt/lib/orc/coff_platform.h
21–25

Does Windows support the POSIX dl* APIs?

I *think* these should probably be renamed to match the corresponding Windows function names, e.g. __orc_rt_LoadLibrary, __orc_rt_GetProcAddress and __orc_rt_FreeLibrary. The high-level __orc_rt_coff_run_program function can then be written in terms of them very similarly to the way that __orc_rt_macho_run_program uses the dlfcn APIs.

The idea here is that we could alias LoadLibrary -> __orc_rt_LoadLibrary for JIT'd code, and then windows code that calls LoadLibrary will work under the JIT*.

All that said -- I'm fine with this landing as-is, and these comments being addressed in follow-up patches.

*We have a long way to go before this is true in general, but we want to move in that direction.

compiler-rt/lib/orc/error.h
116

Nice cleanup! It seems unrelated to the rest of this patch -- can you commit it separately? (No further review needed)

compiler-rt/test/orc/TestCases/Windows/x86-64/lit.local.cfg.py
2–5

Can this just be config.target_arch != "x86_64"? Do we not canonicalize AMD64 -> x86_64?

compiler-rt/test/orc/lit.cfg.py
32–39

Should be formatted for 80-columns.

llvm/include/llvm/ExecutionEngine/Orc/COFFPlatform.h
190

Typo: Bootstraping -> Bootstrapping.

llvm/lib/ExecutionEngine/Orc/COFFPlatform.cpp
218–219

IsBootstrapping is unused outside the condition -- could you just change the condition to (!Bootstrapping)?

387–426

This is the same algorithm as MachO, right? We should look for a way to factor this out, but that can happen in a followup patch.

llvm/lib/ExecutionEngine/Orc/ObjectFileInterface.cpp
220–225

This is missing a return on the error path:

} else
  return SecName.takeError();
llvm/tools/llvm-jitlink/llvm-jitlink.cpp
1070–1074

Maybe add a brief comment here that we always want JIT'd code to be able to call this, even when we don't expose other processes symbols?

1224–1225

Is there any reason to make a distinction between LibName and LibPath here? Could we just use the path as the name?

llvm/tools/llvm-jitlink/llvm-jitlink.h
56

Is this just a map of JITDylib names to JITDylibs? If so I think you could use ExecutionSession::getJITDylibByName instead.

sunho updated this revision to Diff 451808.Aug 11 2022, 5:12 AM
sunho marked 3 inline comments as done.
sunho marked 8 inline comments as done.
sunho added inline comments.
compiler-rt/lib/orc/coff_platform.cpp
59

I coined that term inspired by *nix ;)

compiler-rt/lib/orc/coff_platform.h
21–25

The plan of me is that still keep internal implementation dl* api friendly and implement loadlibrary using dl* api. This allows us to reuse LLJIT platform support class which uses dl* api as it is. Notice that we don't alias dlopen -> __orc_rt_dl_... yet.

compiler-rt/test/orc/TestCases/Windows/x86-64/lit.local.cfg.py
2–5

Not exactly sure what's going on here. On my local machine, only AMD64 works.

llvm/lib/ExecutionEngine/Orc/COFFPlatform.cpp
387–426

I thought the same while doing this. What's more urgent in my opinion is refactor the orc runtime side code to share more code. A lot of code is duplicated across multiple platforms there.

llvm/tools/llvm-jitlink/llvm-jitlink.cpp
1224–1225

It's separated because same DLL can exist in multiple include pathes. All the path stuffs is done to make sure we don't double import the same DLL.

sunho marked 3 inline comments as done.Aug 11 2022, 5:14 AM
sunho updated this revision to Diff 451820.Aug 11 2022, 5:40 AM
v.g.vassilev added inline comments.
compiler-rt/lib/orc/coff_platform.h
2
lhames added inline comments.Aug 11 2022, 9:24 PM
compiler-rt/test/orc/TestCases/Windows/x86-64/lit.local.cfg.py
2–5

Huh. I wonder if that's intended? I'm not curious enough to hold this patch up while I investigate though. Let's stick with what you have. :)

llvm/lib/ExecutionEngine/Orc/COFFPlatform.cpp
387–426

Yeah -- let's get this landed and build some experience with it, and then what we learn can feed into a refactor to share common code.

llvm/tools/llvm-jitlink/llvm-jitlink.cpp
1224–1225

Are DLLs identified by filename alone then? Or is there some other way to tell whether two DLLs represent the same logical library?

sunho updated this revision to Diff 452102.Aug 12 2022, 1:14 AM

Use path as key.

sunho updated this revision to Diff 452110.Aug 12 2022, 2:15 AM
sunho marked an inline comment as done.
sunho marked an inline comment as done.
lhames accepted this revision.Aug 12 2022, 8:09 PM

LGTM! Thanks @sunho! I'm very excited to see this land in-tree. :)

llvm/tools/llvm-jitlink/llvm-jitlink.cpp
1224–1225

Oh -- LibName here comes from `-

This revision is now accepted and ready to land.Aug 12 2022, 8:09 PM
lhames added inline comments.Aug 12 2022, 8:10 PM
llvm/tools/llvm-jitlink/llvm-jitlink.cpp
1224–1225

Oh -- LibName here comes from `-

Disregard that -- it was a stale comment from an earlier pass on the review. :)

This revision was landed with ongoing or failed builds.Aug 12 2022, 9:48 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2022, 9:48 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript

FYI, this commit broke cross compilation with mingw, due to using the mixed-case Windows.h header, but I fixed that in 156136502b73a53192f21fc0477263e76a17a9b9.

However after that, this new file still produces a bunch of warnings:

[1/2] Building CXX object lib/orc/CMak...RTOrc.x86_64.dir/coff_platform.cpp.obj
In file included from ../lib/orc/coff_platform.cpp:20:
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
                                                      ^~~~
../lib/orc/coff_platform.cpp:506:9: warning: unused variable 'JDState' [-Wunused-variable]
  auto &JDState = I->second;
        ^
../lib/orc/coff_platform.cpp:671:44: warning: multi-character character constant [-Wmultichar]
  constexpr uint32_t EH_EXCEPTION_NUMBER = 'msc' | 0xE0000000;
                                           ^
In file included from ../lib/orc/coff_platform.cpp:20: 
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx)) 
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
                                                      ^~~~
../lib/orc/coff_platform.cpp:314:30: note: in instantiation of function template specialization '__orc_rt::WrapperFunction<__orc_rt::SPSExpected<__orc_rt::SPSSequence<__orc_rt::SPSTuple<__orc_rt::SPSExecutorAddr, __orc_rt::SPSSequence<__orc_rt::SPSExecutorAddr>>>> (__orc_rt::SPSExecutorAddr)>::call<__orc_rt::Expected<std::unordered_map<__orc_rt::ExecutorAddr, std::vector<__orc_rt::ExecutorAddr>>>, __orc_rt::ExecutorAddr>' requested here
          SPSExecutorAddr)>::call(&__orc_rt_coff_push_initializers_tag,
                             ^
In file included from ../lib/orc/coff_platform.cpp:20:
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false) 
                                                      ^~~~
../lib/orc/coff_platform.cpp:441:41: note: in instantiation of function template specialization '__orc_rt::WrapperFunction<__orc_rt::SPSExpected<__orc_rt::SPSExecutorAddr> (__orc_rt::SPSExecutorAddr, __orc_rt::SPSSequence<char>)>::call<__orc_rt::Expected<__orc_rt::ExecutorAddr>, __orc_rt::ExecutorAddr, std::string_view>' requested here
          SPSExecutorAddr, SPSString)>::call(&__orc_rt_coff_symbol_lookup_tag,
                                        ^ 
5 warnings generated.

It'd be nice if this could build without warnings.

For what it's worth, this break building compiler-rt with clang-cl:

In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp:16:
In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.h:17:
In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/executor_address.h:20:
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/simple_packed_serialization.h(403,58): error: no member named 'string_view' 
in namespace 'std'
template <> class SPSSerializationTraits<SPSString, std::string_view> {
                                                    ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(109,21): error: no type named 'string_view' in namespace '
std'
  void *dlopen(std::string_view Name, int Mode);
               ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(111,34): error: no type named 'string_view' in namespace '
std'
  void *dlsym(void *Header, std::string_view Symbol);
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(118,34): error: no member named 'string_view' in namespace
 'std'
      std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs,
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(122,34): error: no member named 'string_view' in namespace
 'std'
      std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs);
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(135,36): error: no type named 'string_view' in namespace '
std'
  Expected<void *> dlopenImpl(std::string_view Path, int Mode);
                              ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(143,46): error: no type named 'string_view' in namespace '
std'
  JITDylibState *getJITDylibStateByName(std::string_view Path);
                                        ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(145,54): error: no type named 'string_view' in namespace '
std'
                                                std::string_view Symbol);
                                                ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(156,27): error: no member named 'string_view' in namespace
 'std'
  std::unordered_map<std::string_view, void *> JDNameToHeader;
                     ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(173,55): error: no type named 'string_view' in namespace '
std'

etc.

The problem being that MSVC string_view header doesn't do anything unless building at least in C++17 mode, and for some reason, that's not the case. (In case it matters, this is from a standalone build of compiler-rt)

sunho added a comment.Aug 15 2022, 8:57 AM

FYI, this commit broke cross compilation with mingw, due to using the mixed-case Windows.h header, but I fixed that in 156136502b73a53192f21fc0477263e76a17a9b9.

However after that, this new file still produces a bunch of warnings:

[1/2] Building CXX object lib/orc/CMak...RTOrc.x86_64.dir/coff_platform.cpp.obj
In file included from ../lib/orc/coff_platform.cpp:20:
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
                                                      ^~~~
../lib/orc/coff_platform.cpp:506:9: warning: unused variable 'JDState' [-Wunused-variable]
  auto &JDState = I->second;
        ^
../lib/orc/coff_platform.cpp:671:44: warning: multi-character character constant [-Wmultichar]
  constexpr uint32_t EH_EXCEPTION_NUMBER = 'msc' | 0xE0000000;
                                           ^
In file included from ../lib/orc/coff_platform.cpp:20: 
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx)) 
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
                                                      ^~~~
../lib/orc/coff_platform.cpp:314:30: note: in instantiation of function template specialization '__orc_rt::WrapperFunction<__orc_rt::SPSExpected<__orc_rt::SPSSequence<__orc_rt::SPSTuple<__orc_rt::SPSExecutorAddr, __orc_rt::SPSSequence<__orc_rt::SPSExecutorAddr>>>> (__orc_rt::SPSExecutorAddr)>::call<__orc_rt::Expected<std::unordered_map<__orc_rt::ExecutorAddr, std::vector<__orc_rt::ExecutorAddr>>>, __orc_rt::ExecutorAddr>' requested here
          SPSExecutorAddr)>::call(&__orc_rt_coff_push_initializers_tag,
                             ^
In file included from ../lib/orc/coff_platform.cpp:20:
../lib/orc/wrapper_function_utils.h:299:27: warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
    if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
                        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
../lib/orc/compiler.h:60:55: note: expanded from macro 'ORC_RT_UNLIKELY'
#define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false) 
                                                      ^~~~
../lib/orc/coff_platform.cpp:441:41: note: in instantiation of function template specialization '__orc_rt::WrapperFunction<__orc_rt::SPSExpected<__orc_rt::SPSExecutorAddr> (__orc_rt::SPSExecutorAddr, __orc_rt::SPSSequence<char>)>::call<__orc_rt::Expected<__orc_rt::ExecutorAddr>, __orc_rt::ExecutorAddr, std::string_view>' requested here
          SPSExecutorAddr, SPSString)>::call(&__orc_rt_coff_symbol_lookup_tag,
                                        ^ 
5 warnings generated.

It'd be nice if this could build without warnings.

Thanks for reporting this. I'll look into it.

sunho added a comment.Aug 15 2022, 8:58 AM

For what it's worth, this break building compiler-rt with clang-cl:

In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp:16:
In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.h:17:
In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/executor_address.h:20:
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/simple_packed_serialization.h(403,58): error: no member named 'string_view' 
in namespace 'std'
template <> class SPSSerializationTraits<SPSString, std::string_view> {
                                                    ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(109,21): error: no type named 'string_view' in namespace '
std'
  void *dlopen(std::string_view Name, int Mode);
               ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(111,34): error: no type named 'string_view' in namespace '
std'
  void *dlsym(void *Header, std::string_view Symbol);
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(118,34): error: no member named 'string_view' in namespace
 'std'
      std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs,
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(122,34): error: no member named 'string_view' in namespace
 'std'
      std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs);
                            ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(135,36): error: no type named 'string_view' in namespace '
std'
  Expected<void *> dlopenImpl(std::string_view Path, int Mode);
                              ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(143,46): error: no type named 'string_view' in namespace '
std'
  JITDylibState *getJITDylibStateByName(std::string_view Path);
                                        ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(145,54): error: no type named 'string_view' in namespace '
std'
                                                std::string_view Symbol);
                                                ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(156,27): error: no member named 'string_view' in namespace
 'std'
  std::unordered_map<std::string_view, void *> JDNameToHeader;
                     ~~~~~^
/builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(173,55): error: no type named 'string_view' in namespace '
std'

etc.

The problem being that MSVC string_view header doesn't do anything unless building at least in C++17 mode, and for some reason, that's not the case. (In case it matters, this is from a standalone build of compiler-rt)

We have enabled c++17 in entire llvm code base recently. But, I think standalone compiler-rt doesn't enable c++17 by themselves yet.

yingcong-wu reopened this revision.Sep 7 2022, 8:31 PM
yingcong-wu added a subscriber: yingcong-wu.

check-all failed with those tests:

ORC-x86_64-windows :: TestCases/Windows/x86-64/hello-world.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/hello-world.cpp
ORC-x86_64-windows :: TestCases/Windows/x86-64/priority-static-initializer-three.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/priority-static-initializer.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/sehframe-handling.cpp
ORC-x86_64-windows :: TestCases/Windows/x86-64/static-initializer.S
ORC-x86_64-windows :: TestCases/Windows/x86-64/static-initializer.cpp

Directly caused by incorrect orc runtime library filename in Windows.

But after changing the filename in compiler-rt/test/orc/lit.cfg.py, tests reported

llvm-jitlink error: Could not find symbol at given index, did you add it to JITSymbolTable? index: 441, section: 3001
D:\bin\llvm-jitlink.exe: Failed to materialize symbols: { (main, { __orc_rt_coff_symbol_lookup_tag }) }

Build Info

  • Build type: Debug
  • Target: X86
  • In tree build

Could you please give me some clues?

compiler-rt/test/orc/lit.cfg.py
17–20

In my local build in X86 Windows, the orc runtime library filename is clang_rt.orc-x86_64.lib.

This revision is now accepted and ready to land.Sep 7 2022, 8:31 PM
sunho added a comment.Sep 9 2022, 11:01 PM

check-all failed with those tests:

ORC-x86_64-windows :: TestCases/Windows/x86-64/hello-world.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/hello-world.cpp
ORC-x86_64-windows :: TestCases/Windows/x86-64/priority-static-initializer-three.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/priority-static-initializer.c
ORC-x86_64-windows :: TestCases/Windows/x86-64/sehframe-handling.cpp
ORC-x86_64-windows :: TestCases/Windows/x86-64/static-initializer.S
ORC-x86_64-windows :: TestCases/Windows/x86-64/static-initializer.cpp

Directly caused by incorrect orc runtime library filename in Windows.

But after changing the filename in compiler-rt/test/orc/lit.cfg.py, tests reported

llvm-jitlink error: Could not find symbol at given index, did you add it to JITSymbolTable? index: 441, section: 3001
D:\bin\llvm-jitlink.exe: Failed to materialize symbols: { (main, { __orc_rt_coff_symbol_lookup_tag }) }

Build Info

  • Build type: Debug
  • Target: X86
  • In tree build

Could you please give me some clues?

I believe it's related to build type -- we always try to load up release build of vc runtime libs which can fail in debug build of compiler-rt. I was aware of different library name, but I just wasn't sure exactly when different name happens. Could you share more details on your build setting and error log?

sunho added a comment.Sep 11 2022, 6:53 AM

Turned out the different library name was made by a bug in compiler-rt cmake file -- my local build was generating ".a" library files. It should be fixed in https://reviews.llvm.org/D133669. I'll update the code to use just ".lib" I'll invastigate the symbol not found failure shortly.

Turned out the different library name was made by a bug in compiler-rt cmake file -- my local build was generating ".a" library files. It should be fixed in https://reviews.llvm.org/D133669. I'll update the code to use just ".lib" I'll invastigate the symbol not found failure shortly.

Glad to hear that.

Could you share more details on your build setting and error log?

The error log is really not much to shared. As for my build settings, I was built with VS2022 under u4win environment as well as the native windows environment. If you want to know something specific, please just ask me.