[GHC] #5435: GHCi linker should run constructors for linked libraries

[GHC]

#5435: GHCi linker should run constructors for linked libraries
-------------------------------------+------------------------------------
        Reporter:  pumpkin           |            Owner:
            Type:  bug               |           Status:  infoneeded
        Priority:  normal            |        Milestone:  7.8.1
       Component:  Compiler          |          Version:  7.2.1
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:  3658
        Blocking:  7746, 8199        |  Related Tickets:  #3658
-------------------------------------+------------------------------------

Comment (by ezyang):

 While fixing this, I found a few more bugs, which are going to be a bit
 annoying to fix:

 * The current dynamic test is really a test for loading a static library
 that happens to be PIC'd. We need to explicitly use addDLL to load a
 shared library. In fact, we can run a statically linked executable and
 still load a DLL.

 * But we can't reuse this test for Windows, because on Linux/Mac OS X,
 addDLL requires a file extension, while on Windows, we must omit it. So we
 need two tests here.

 * Also, on Windows, when I pass `-dynamic` when building the C DLL causes
 errors like `C:/Users/ezyang/Dev/ghc-init/inplace/mingw/bin/ld.exe: cannot
 find -lHSbase-4.7.0.0-ghc7.7.20130905`; no problem, just omit the flag.
 But this is harmless on Linux, so maybe there is a bug here.

 * With the dynamic test working, I found that actually, `ctors` is
 reversed, so I need to revert the behavior back to the reversed version.
 (I had it that way originally, but flipped it due to the buggy test case)

 * Then I found out that, actually, the order MingW GCC compiles
 `__attribute__(constructor)` to run is reverse of how it compiles it on
 Linux. I think this might be a bug, but I couldn't find anywhere where GCC
 said that they were going to run in any specific order. But this means to
 keep the test cases consistent, we need to manually lay out the ctors
 section ourself. No problem, so we need two tests: one for a C
 compilation, and one for a assembly compilation (with all of the various
 ways an initializer can be spelled). Obviously this doesn't apply to
 Mach-O.

 * Then I wondered, "Well, what happens if there are both ctors and
 init_array and init; is there a prescribed order these should run in, or
 is it just the order they show up in the sections?" Well, the dynamic
 linker will guidance here.

 * I also tried to induce ordering with priority, but I found out that GCC
 compiles constructor priority by tacking on a number to the name of the
 ctors section; I didn't write support for that but maybe I should.

 * And then Anders pointed out to me that in C++, the order of constructors
 in the compilation unit is guaranteed, and it seems unlikely GCC would use
 priority to manage that, so that would be an easy way to find out if MingW
 GCC was buggy; but if it is buggy, what can we do?

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