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

GHC cvs-ghc at haskell.org
Sun Apr 28 23:55:52 CEST 2013


#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):

 OK - that explains what I couldn't understand.

 Take a look at a file called libffi/build/src/arm/ffi.c on line 486:
 ffi_closure_alloc(). This is inside #if FFI_EXEC_TRAMPOLINE_TABLE which is
 true on iOS. This is the very clever LIBFFI code to get around Apple's
 restrictions.

 On iOS therefore, ffi_closure_alloc() treats the returned void* is a
 structure of type ffi_closure, stuffing some values into it prior to
 returning it. In order to allocate memory for associating the
 writable/exec addresses, our Linux version advances the pointer before
 returning it. This means that on Linux, the value later passed to
 ffi_prep_closure_loc() (first argument) is not the same as the one
 returned by ffi_closure_alloc().

 Look at ffi.c again on line 604: ffi_prep_closure_loc(). The passed
 pointer (first parameter) is assumed to be of type ffi_closure. In the
 FFI_EXEC_TRAMPOLINE_TABLE implementation ffi_prep_closure_loc() doesn't
 use the values stuffed in during ffi_closure_alloc(), but the closure code
 itself uses them. You can see that advancing the pointer before passing it
 to ffi_prep_closure_loc() (as we do in our Linux implementation) would
 then violate an important assumption that exists in the
 FFI_EXEC_TRAMPOLINE_TABLE implementation - that the address returned by
 ffi_closure_alloc() is the same as the one passed to
 ffi_prep_closure_loc(). And, indeed when we do this, it crashes.

 In this implementation, the exec and writable pointers don't refer to the
 same memory. You can see this on lines 473 and 521. So, this completely
 rules out the method we use on Linux as I explained previously.

 I told you it was complicated.

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



More information about the ghc-tickets mailing list