[GHC] #7718: ios patch no 8: adjustor pools

[GHC]

#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