#5292: libHSghc exports more symbols than Windows can handle
---------------------------------+------------------------------------------
    Reporter:  batterseapower    |        Owner:               
        Type:  bug               |       Status:  new          
    Priority:  normal            |    Milestone:  7.4.1        
   Component:  Compiler          |      Version:  7.0.3        
    Keywords:                    |     Testcase:               
   Blockedby:                    |   Difficulty:               
          Os:  Windows           |     Blocking:               
Architecture:  Unknown/Multiple  |      Failure:  Runtime crash
---------------------------------+------------------------------------------

Comment(by batterseapower@…):

 commit 0e765db44229aed591f9f423ef909b5f76696de0
 {{{
 Author: Max Bolingbroke <[email protected]>
 Date:   Fri Jul 29 12:05:46 2011 +0100

     Add CoreMonad.reinitializeGlobals so plugins can work around linker
 issues

     When a plugin is loaded, it currently gets linked against a *newly
 loaded* copy
     of the GHC package. This would not be a problem, except that the new
 copy has its
     own mutable state that is not shared with that state that has already
 been initialized by
     the original GHC package.

     This leads to loaded plugins calling GHC code which pokes the static
 flags,
     and then dying with a panic because the static flags *it* sees are
 uninitialized.

     There are two possible solutions:
       1. Export the symbols from the GHC executable from the GHC library
 and link
          against this existing copy rather than a new copy of the GHC
 library
       2. Carefully ensure that the global state in the two copies of the
 GHC
          library matches

     I tried 1. and it *almost* works (and speeds up plugin load times!)
 except
     on Windows. On Windows the GHC library tends to export more than 65536
 symbols
     (see #5292) which overflows the limit of what we can export from the
 EXE and
     causes breakage.

     (Note that if the GHC exeecutable was dynamically linked this wouldn't
 be a problem,
     because we could share the GHC library it links to.)

     We are going to try 2. instead. Unfortunately, this means that every
 plugin
     will have to say `reinitializeGlobals` before it does anything, but
 never mind.

     I've threaded the cr_globals through CoreM rather than giving them as
 an
     argument to the plugin function so that we can turn this function into
     (return ()) without breaking any plugins when we eventually get 1.
 working.

  compiler/HsVersions.h            |   14 ++++----
  compiler/ghci/Linker.lhs         |   56 ++++++++++++++++++++++-------
  compiler/main/StaticFlags.hs     |   24 ++++++++++++-
  compiler/simplCore/CoreMonad.lhs |   72
 +++++++++++++++++++++++++++++++++++---
  compiler/utils/Util.lhs          |   10 ++----
  5 files changed, 142 insertions(+), 34 deletions(-)
 }}}

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

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to