#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