GitLab

- If two "type instance"s overlap, they right-hand sides must be syntactically
  equal under the overlap substitution.  (Ie, we admit limited overlap, but
  require the system to still be confluent.)

Per suggestions from Simon M:

* Changed GHC.checkModule so that it doesn't call depanal.
* Changed GHC.checkModule to optionally return Core bindings
as a component of the CheckedModule that it returns (and 
resulting changes to HscMain.hscFileCheck).
* As a result, simplified GHC.compileToCore and changed it
to load the given file so that the caller doesn't have to.

When linking against a dynamic library, the linker will emit a warning
if no type information is present within the library. We generate the
most trivial type for all externally visible labels, namely @object.

The GNU linker expects read-only sections to be relocation
free. Presumably because the dynamic linker maps all read-only
sections as read-only mmaps and hence can't do relocations.

If we want text-relocation-free shared libraries we have to put all
relocations into writable sections, hence .data.  See
http://www.mail-archive.com/cvs-all@haskell.org/msg15119.html

To create a dynamic shared object (DSO) on ELF platforms, we invoke
"gcc -shared". This in turn invokes ld. We supply -Bsymbolic to the
linker, as "ld -Bsymbolic -shared -o <lib> <objs>" resolves all
references from <objs> to <objs> at library creation time. 

See http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode

function: staticLink -> linkBinary (will link non static binaries too)
function: doMkDLL -> linkDynLib (as we can link on ELF too where DLL is an inappropriate term)
constructor: MkDLL -> LinkDynLib

CmmLabelDiffOff are generated in .text and if printed as .quad, causes
the assembler to emit a PC64 relocation. binutils prior to 2.17 don't
understand PC64 relocation properly.

pprDataItem is also used for printing SRT description tables. They are
part of the .data section and there no PC relative relocations are
emited. Hence, if we print a .long here, we get a absolute 32-bit
relocation. 32-bit relocations are problematic in dynamic libraries,
because dynamic library load addresses are loaded beyond the 32 bit
boundary, causing the dynamic linker to warn at dynamic linking
(loading the executable) that there are overflows in the
relocation. The executable still seems to work because of the small
memory model, but this is obviously wrong. Hence, remove CmmLabelOff
from the classification, causing these references to be printed as
.quad, causing correct 64-bit relocation as in the rest of the .data
section.  

So, this hack now prints PC32 relocations in .text (mostly in the info
tables), and absolute 64-bit relocations in .data.

tcSplitFunTy_maybe wasn't dealing with types like
	(?x::Bool) => Int
Here, tcSplitFunTy_maybe should fail (as it would if there
was a for-all), because the type is a quantified type.

See Trac #1445, and test tc230.

Modified compileToCore to take just a session and a 
filename, rather than a module name as well, since the module
name can be computed from the filename. 

When debugging the GC and storage manager we often want repeated runs
of the program to allocate memory at the same addresses, so that we
can set watch points.  Unfortunately the OS doesn't always give us
memory at predictable addresses.  This flag gives the OS a hint as to
where we would like our memory allocated.  Previously I did this by
changing the HEAP_BASE setting in MBlock.h and recompiling, this patch
just adds a flag so I don't have to recompile.

- Thanks to Roman for spotting the problem.

- We forgot to pull the data declarations nested in class instances out of
  the instances when collecting all the predicates that we need derive.
  Thanks to Roman for spotting this.

We needed to turn some inline C functions and C macros into either
real C functions or C-- macros.

Added a compileToCore function to the GHC API that takes a
  session, module, and filename, and returns a list of Core
  bindings if successful. This is just a first try and could
  probably be improved (for example, there's probably a way to
  get the filename from the module so that it doesn't have to 
  be passed in, I just don't see it offhand.)