#13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Hmm, Interesting, thanks for the report. I think the error message is also a bit of a regression. It seems we currently abort inside the `rts` while we used to return and let the Haskell code resolve it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103, #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I have my custom ''shared libraries'' build of llvm on MinGW-w64 and `llvm-general` works just fine with it. Thus `-fshared-llvm` requirement is important. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f41c27d3ffdddbb1afe07de1bd25205061194c93/ghc" f41c27d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f41c27d3ffdddbb1afe07de1bd25205061194c93" Slighly clean up symbol loading error. The symbol not found error that is triggered during lazy-loading was a bit chaotic before. This reformats it a bit to: ``` ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev' ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv' ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved. See top entry above. ``` I have also thought about also showing the demangled names, as it may be useful for the end user. `libgcc` seems to provide a method for this so we wouldn't need any extra dependency. Any thoughts on this or would it not be useful? Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3027 GHC Trac Issues: #13093, #13113 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No, this one requires a final fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"41e54b4b1a2934364759edcf77ba1f5b03a4098f/ghc" 41e54b4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="41e54b4b1a2934364759edcf77ba1f5b03a4098f" Load dependent dlls. When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Unfortunately due to time constraints I can't set up the framework required in `GHC` to do this before the feature freeze. So I suggest this alternate implementation: When we load a dll, also bring it's dependencies into scope of the interpeter. This has pros and cons. Pro is, we'll fix many packages on hackage which specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which will bring `libgcc` into scope. The downside is, we'll be more lenient than GCC, in that the interpreter will link much easier since it has implicit dependencies in scope. Whereas for compilation to work you will have to specify it as an argument to GHC. This will make the Windows runtime linker more consistent with the unix ones. The difference in semantics came about because of the differences between `dlsym` and `GetProcAddress`. The former seems to search the given library and all it's dependencies, while the latter only searches the export table of the library. So we need some extra manual work to search the dependencies which this patch provides. Test Plan: ``` ./validate ``` ``` $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS -lstdc++ 2>&1 | grep "Loading dependency" ``` ``` $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS -Dl -RTS 2>&1 | grep "Loading dependency" Loading dependency *.exe -> GDI32.dll. Loading dependency GDI32.dll -> ntdll.dll. Loading dependency *.exe -> KERNEL32.dll. Loading dependency KERNEL32.dll -> KERNELBASE.dll. Loading dependency *.exe -> msvcrt.dll. Loading dependency *.exe -> SHELL32.dll. Loading dependency SHELL32.dll -> USER32.dll. Loading dependency USER32.dll -> win32u.dll. Loading dependency *.exe -> WINMM.dll. Loading dependency WINMM.dll -> WINMMBASE.dll. Loading dependency *.exe -> WSOCK32.dll. Loading dependency WSOCK32.dll -> WS2_32.dll. Loading dependency WS2_32.dll -> RPCRT4.dll. Loading dependency libstdc++-6.dll -> libwinpthread-1.dll. Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll. ``` Trac tickets: #13093, #13189 Reviewers: simonmar, rwbarton, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3028 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) * status: closed => new * resolution: fixed => Comment: No it requires Phab:D3082 (msvc generates files with extension .obj). But also requires a final patch that I have yet to write. That's what I meant in comment:10 :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Comment (by Phyx-): New linker is making some significant progress here as well {{{ Tamar@Destiny MINGW64 /e/temp $ echo "main" | ~/ghc/inplace/bin/ghc-stage2.exe --interactive LLVM.hs $(llvm-config --libs --link-static) $(llvm-config --system-libs --link- static) -L/mingw64/lib/ -lstdc++ -lgcc GHCi, version 8.3.20170812: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( LLVM.hs, interpreted ) Ok, 1 module loaded. *Main> Access violation in generated code when reading ffffffffffffffff }}} The LLVM libraries require the new `big-obj` support and also require proper section alignment support which now works. The remaining problem is that it's C++ and requires proper support for Constructors and Destructors via `__DTOR_LIST__` and `__CTOR_LIST__`. However I lack some knowledge of how the C++ ABI and linking work so I'll need to read up before I can add this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13093#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler