#7718: ios patch no 8: adjustor pools --------------------------------+------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: 7724 | Related: --------------------------------+------------------------------------------- Comment(by StephenBlackheath): It's specifically the iOS version of libffi (not ARM) that has the assumption that ffi_closure_alloc() / ffi_prep_closure_loc() are dealing with a ffi_closure*, and currently the RTS assumes we can do whatever we like with this memory (these two assumptions being incompatible). As you say, if the RTS managed both addresses and was able to pass the write address back to freeExec, we wouldn't need the hash table I put into my ios-patch-8e. The executable pointer is the only one that gets passed to C code when you use a FunPtr through the FFI, though. Even though it would be unusual, it seems that it is possible to pass a FunPtr that originated with a 'foreign import ccall "wrapper"' into C code and back out, and then freeHaskellFunPtr it. If this is so, I can't see how the hash table can be completely avoided. I think it's a reasonable compromise to go with my ios-patch-8e and pay a small performance penalty on freeHaskellFunPtr on iOS only rather than complicating the RTS for the benefit of a single architecture. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7718#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler