[GHC] #9878: Static pointers in GHCi cause panic

[GHC]

#9878: Static pointers in GHCi cause panic
-------------------------------------+-------------------------------------
              Reporter:  monoidal    |            Owner:  facundo.dominguez
                  Type:  bug         |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.9
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:  GHCi crash  |       Blocked By:
             Test Case:              |  Related Tickets:
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by facundo.dominguez):

 My plan to address this issue would be as follows:

 * In the renamer, try to infer from dflags whether ghci is compiling
 bytecode and reject the static form.
 * Integrate Alexander's patch to fix {{{hs_spt_keys}}}.
 * Document the unavailability of static forms for bytecode.

 The API in GHC.StaticPtr is not designed to support dynamic loading. We
 would need to make lookups and staticPtrKeys monadic. It's doable but it
 needs green lights from SPJ and Mathieu.

 Then we need to decide what to do with the SPT implementation. To make it
 thread-safe we can use a readers-writer lock implemented with mutexes, or
 maybe someone can suggest a better alternative.

 -- end of plan --

 In addition, if you really want to support static pointers when compiling
 bytecode, then the question is how to link the {{{_stubs.c}}} files
 produced by StaticPointers which contain external symbols expected to be
 defined as top-level values in the corresponding modules.

 One possibility is to discard the stub file when in GHCi, and have GHCi
 call hs_spt_insert directly after linking a module.

 Another alternative is to modify the stub to get the pointers to the top-
 level functions of the module in some other way.

 I know nothing of how GHCi links the bytecode. Someone else would have to
 comment if these ideas have any legs.

 -- end of comments for StaticPointers --

 HPC may need a different solution. The external symbol which appears in
 {{{stub.c}}} is produced at the C-- level, so it would not have a byte-
 code incarnation as top-level values do for StaticPointers.

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