[GHC] #7722: iOS patch no 11: Fix quirk with runtime loader

[GHC]

#7722: iOS patch no 11: Fix quirk with runtime loader
----------------------------------+-----------------------------------------
    Reporter:  StephenBlackheath  |       Owner:              
        Type:  feature request    |      Status:  patch       
    Priority:  normal             |   Milestone:              
   Component:  Compiler           |     Version:  7.7         
    Keywords:                     |          Os:  Other       
Architecture:  arm                |     Failure:  None/Unknown
  Difficulty:  Unknown            |    Testcase:              
   Blockedby:                     |    Blocking:  7724        
     Related:                     |  
----------------------------------+-----------------------------------------

Comment(by StephenBlackheath):

 I don't fully understand it either. I don't think there's anything special
 about free apart from - I assume - getting resolved at runtime. Here's
 what the darwin -> iOS C compiler produces for {{{printf("%p\n", free);}}}

 {{{
         movw    r0, :lower16:(L_free$non_lazy_ptr-(LPC0_0+4))
         movt    r0, :upper16:(L_free$non_lazy_ptr-(LPC0_0+4))
 LPC0_0:
         add     r0, pc
         ldr     r1, [r0]            <-- r1 being the second argument of
 printf
 ...
         .section        __DATA,__nl_symbol_ptr,non_lazy_symbol_pointers
         .align  2
 L_free$non_lazy_ptr:
         .indirect_symbol        _free
         .long   0
 }}}

 Here's what GHC produces WITHOUT my patch, and this is the code that dies
 at runtime if you say 'print Data.ByteString.empty'. The source file is
 libraries/bytestring/Data/ByteString/Unsafe.hs

 {{{
         .text
         .align  2
 _s2jH_info:                             @ @s2jH_info
 ...
         ldr     r9, LCPI29_2
 ...
         .align  2
 LCPI29_2:
         .long   _free      <-- still under the .text above, i.e. in text
 segment

 }}}

 Here's what GHC produces WITH my patch:

 {{{
         .text
         .align  2
 _s2jH_info:                             @ @s2jH_info
 ...
         ldr     r8, LCPI29_1
 ...
         ldr     r9, [r8]
 ...
         .align  2
 LCPI29_1:
         .long   _free_ref_n3dd
 ...
         .section        __DATA,__data
 ...
         .align  3                       @ @free_ref_n3dd
 _free_ref_n3dd:
         .long   _free
 }}}

 I don't know what .indirect_symbol does (and my assumption would be that
 llvm can't output it), but it certainly looks like the C compiler has also
 made sure the reference to _free is in the DATA segment. And my code has
 (surprisingly) fewer instructions than the C output.

 My priority has been to get things working, and not so much on proving the
 necessity or showing that it's the best way. Do you think this satisfies
 your questions about whether the changes are justified? If not, I'll
 investigate further.

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