Implement .init/.init_array support for ELF.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Place static closures in their own section.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
BC-breaking changes to C-- CLOSURE syntax.

Previously, there were two variants of CLOSURE in C--:

    - Top-level CLOSURE(foo_closure, foo, lits...), which defines a new
      static closure and gives it a name, and

    - Array CLOSURE(foo, lits...), which was used for the static char
      and integer arrays.

They used the same name, were confusing, and didn't even generate
the correct internal label representation!  So now, we have two
new forms:

    - Top-level CLOSURE(foo, lits...) which automatically generates
      foo_closure (along with foo_info, which we were doing already)

    - Array ANONYMOUS_CLOSURE(foo, lits...) which doesn't generate
      a foo_closure identifier.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Properly generate info tables for static closures in C--.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Rename _closure to _static_closure, apply naming consistently.

In preparation for indirecting all references to closures,
we rename _closure to _static_closure to ensure any old code
will get an undefined symbol error.  In order to reference
a closure foobar_closure (which is now undefined), you should instead
use STATIC_CLOSURE(foobar).  For convenience, a number of these
old identifiers are macro'd.

Across C-- and C (Windows and otherwise), there were differing
conventions on whether or not foobar_closure or &foobar_closure
was the address of the closure.  Now, all foobar_closure references
are addresses, and no & is necessary.

CHARLIKE/INTLIKE were not changed, simply alpha-renamed.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Implement closure indirections.

Closure indirections live in the staticclosureinds section
and initially point to their corresponding closure in
the staticclosures.  The intent is that all code goes through
a closure indirection, and at runtime the indirections can
change.

These pieces of code have to go through closure indirections:

    - Code references to a static closure
    - SRTs
    - Heap check (but we want to fix this)
    - References to closures in RTS (see STATIC_CLOSURE) macro
    - Runtime symbol lookup (e.g. GHCi, dynwrapper)
    - The main closure passed to hs_main

Closure indirections should simplify these components (but that
is not implemented yet):

    - Windows DLL handling (which already needed an indirection)

In order to keep the code running, the fields of static closures
are not indirected (although they should be); this will be switched
over in a later commit.

Important invariant: an indirection may only be dereferenced
after the runtime is setup.  In particular, references to
closures in __attribute__(constructor) need to be kept indirections;
this is what the stable pointer deferral is for.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Implement runtime setup code for static closures.

Fields of static closures are now indirected, and we have a simple
runtime initialization code initStaticClosures() which merely rewrites
all of the indirections into untagged pointers and untangles references
between the static closures.  This also copies static closures into
blocks, although this data is unused.

The runtime system finds out about indirections by way of
__attribute__(constructor) methods; thus C-- compilation may now
generate foreign stubs (if it defines closures).

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Indirect SRTs and heap checks.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
CHARLIKE/INTLIKE must use indirections.

While these are "closures", they aren't allocated the usual
way, so we just special case them in closure initialization.

It is very important that these arrays fit in a single block,
since a pointer to a closure across the boundary needs to have
the appropriate BF_STATIC flag set.

Nota bene: C will implicitly dereference the _ind reference,
but C-- will not; thus the extra load in C-- land.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Closure tables must use indirections.

ToDo: This could be improved by short-circuiting the indirections in the
closure table.  However, we have to arrange for the RTS to know about
all of our closure tables, which is a bit annoying to do.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Add some thread-safety.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Replace HEAP_ALLOCED with block descriptor check.

Blocks have a new flag BF_STATIC, which indicates if the data
contained therein is static.  This means we can get rid of
all of the complicated caching logic in MBlock.h.  For now,
we still maintain the memory mapping, so we can deallocate
all our memory at the end and do some sanity checks.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Move tag from outside to inside indirection.

In the old world, code referring to a closure had code like:

    foobar_closure + tag

Previously, when there was no dereference, this was essentially
free; but in the new world, we have:

    *foobar_static_closure_ind + tag

and that means a few extra instructions at runtime.  But
we can store the tag in the indirection itself, to simplify
the code back to:

    *foobar_static_closure_ind

A bit of stuff needs to be rewired. One important thing:
CHARLIKE/INTLIKE do *not* do this scheme, since there isn't
a separate tagged pointer for each closure, and it's free
anyway, since we already need to add an offset to index
into the appropriate little object.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Reduce number of exported symbols (e.g. _static_closure)

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Resource limits v2

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Multi-cap support! Maybe it works.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Reorganize to store gc_thread in RCs

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
GC partial

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Everything except Evac and Scav

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Cutover.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>