[GHC] #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers

[GHC]

#7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers
-------------------------------------------------+--------------------------
    Reporter:  singpolyma                        |       Owner:               
        Type:  bug                               |      Status:  new          
    Priority:  normal                            |   Milestone:  7.8.1        
   Component:  Compiler (FFI)                    |     Version:  7.7          
    Keywords:  qnx unregisterised cross-compile  |          Os:  QNX          
Architecture:  arm                               |     Failure:  Runtime crash
  Difficulty:  Unknown                           |    Testcase:               
   Blockedby:                                    |    Blocking:  7610         
     Related:                                    |  
-------------------------------------------------+--------------------------

Comment(by psycotica0):

 I've looked into this, and have decided that whether or not GHC is
 correct, libffi is definitely worong.

 The following code works under arm-linux-gnueabi and native, but not under
 qnx:
 {{{

 #include <stdio.h>
 #include <ffi.h>

 /* Acts like puts with the file given at time of enclosure. */
 void puts_binding(ffi_cif *cif, unsigned int *ret, void* args[],
                 FILE *stream)
         {
                 *ret = fputs(*(char **)args[0], stream);
                 }

                 int main()
         {
                 ffi_cif cif;
                 ffi_type *args[1];
                 ffi_closure *closure;

                 int (*bound_puts)(char *);
                 int rc;

                 /* Allocate closure and bound_puts */
                         closure = ffi_closure_alloc(sizeof(ffi_closure),
 &bound_puts);

                 if (closure)
                         {
                                 /* Initialize the argument info vectors */
                                         args[0] = &ffi_type_pointer;

                                 /* Initialize the cif */
                                         if (ffi_prep_cif(&cif,
 FFI_DEFAULT_ABI, 1,
                                         // if (ffi_prep_cif(&cif, FFI_VFP,
 1,
                                         // if (ffi_prep_cif(&cif,
 FFI_SYSV, 1,
 &ffi_type_uint, args) == FFI_OK)
                                         {
                                                 /* Initialize the closure,
 setting stream to stdout */
                                                         if
 (ffi_prep_closure_loc(closure, &cif, puts_binding,
 stdout, bound_puts) == FFI_OK)
                                                         {
                                                                 rc =
 bound_puts("Hello World!");
                                                                 /* rc now
 holds the result of the call to fputs */
                                                                         }
                                                 }
                                 }

                 /* Deallocate both closure, and bound_puts */
                         ffi_closure_free(closure);

                 return 0;
                 }
 }}}

 The formatting's a little off, because I cut and paste it from the libffi
 documentation.
 So, that crashes stacks when built with gcc and run on qnx.

 I looked into libffi some and found that the problem seems to be in two
 calls of `__clear_cache`, which are meant to clear arm's instruction and
 data caches, since it's doing tricky stuff in there.
 They appear to be causing trouble, though...

 Seems like this person
 [http://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc8096
 was having the same trouble with Python on QNX]

 `__clear_cache` appears to be Linux syscall thing on ARM for this, and
 while the code is building on QNX, maybe it works differently there, or is
 broken?

 Either way, I think I'll have to work on this with the FFI people unless
 any of you know what's up.

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