Re: [GHC] #13624: loadObj() does not respect alignment

12 Oct 2018

      #13624: loadObj() does not respect alignment
-------------------------------------+-------------------------------------
        Reporter:  tmcdonell         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.8.1
       Component:  Runtime System    |              Version:  8.0.1
  (Linker)                           |             Keywords:  linker,
      Resolution:                    |  newcomer
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:  8949
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by George):

 Trying to find out if MacOS on 8.6.1 is one of the platforms where this
 needs to be fixed but I can't reproduce:

 {{{
 ./build.sh
 + llc -filetype=obj -mcpu=native map.ll
 + ghc --make -no-hs-main test.c
 bash-3.2$ ./a.out
 array size is 31
 calling function...
 ok
 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0
 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0
 bash-3.2$ lldb a.out
 (lldb) target create "a.out"
 Traceback (most recent call last):
   File "<input>", line 1, in <module>
   File
 "/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py",
 line 52, in <module>
     import weakref
   File
 "/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/weakref.py",
 line 14, in <module>
     from _weakref import (
 ImportError: cannot import name _remove_dead_weakref
 Current executable set to 'a.out' (x86_64).
 (lldb) quit
 quit
 }}}

 I don't understand why lldb is needed to reproduce this in any case, in
 particular how it changes the arr could you explain. Above it says "The
 #define N on line 7 will change the size of the array...For 32 elements or
 larger (i.e. entering the core loop) the program will (almost certainly)
 segfault. " I trying changing N to 32 but then running build.sh a.out just
 worked, no segfault.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13624#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler