[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