[GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object

[GHC]

#10761: GHC panic when compiling vimus: failed to map segment from shared object
-------------------------------------+-------------------------------------
        Reporter:  haasn             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.2
      Resolution:                    |                Keywords:
Operating System:  Linux             |            Architecture:  x86_64
 Type of failure:  Compile-time      |  (amd64)
  crash                              |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 Ultimately Cabal is doing something fragile here, by invoking ghc on only
 the Haskell sources, and not passing it the C sources or object files. If
 the Haskell source contains a Template Haskell splice that actually uses a
 function defined in a C source file then this can't possibly ever work. If
 there is a Template Haskell splice that uses another module from the
 current package that also happens imports a function from a C source file,
 this might work depending on the details of the linker. The temporary
 shared object loaded to run the splice will certainly contain an undefined
 symbol, but this may or may not be a problem.

 Relevant factors include

 * Whether the library is marked for lazy binding of functions (PLT
 references). If the binding is lazy, then the load will not fail and the
 Template Haskell splice runner will be able to use the shared library as
 long as it does not actually need to call the function in question. If the
 binding is not lazy then the load will fail (`Loading temp shared object
 failed: [...] undefined symbol: [...]`).

   Lazy binding is normally the default but in some hardened systems or
 build environments such as haasn's it is not.

 * Whether the foreign call refers to the C symbol by a PLT or GOT entry.
 GOT entries cannot be resolved at call time because the reference is not
 necessarily a call. Why would we call a C function through a GOT entry?
 Well if optimizations are not enabled then the code generator for an STG
 foreign call produces Cmm like
 {{{
            _cJW::I64 = foobarbaz;
            call "ccall" arg hints:  []  result hints:  [] (_cJW::I64)();
 }}}
   and to the backend this looks like a general reference to an object
 followed by an indirect function call. We can and probably should fix this
 but it doesn't fix the actual issue here.

 In my opinion it would make more sense for Cabal to just provide the C
 sources or object files to the ghc invocation. But also see
 https://github.com/haskell/cabal/issues/1738 which points out a problem
 with that idea. Should Cabal have two categories of C source files, one
 that consists of dependencies of the Haskell code and one that consists of
 source files that have foreign export stub headers as dependencies? I
 would think that since Cabal is intended for building Haskell libraries
 that the first category would be much greater...

 I don't know if it makes sense to do anything here in GHC besides being
 aware of the issue and setting `ghc-options: -optl-Wl,z,lazy` when
 building on systems where it is not the default as a workaround.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10761#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler