ghc: initial AArch64 patches

Signed-off-by: Austin Seipp <austin@well-typed.com>
Be less untruthful about the prototypes of external functions

GHC's generated C code uses dummy prototypes for foreign imports.  At the
moment these all claim to be (void), i.e. functions of zero arguments.  On
most platforms this doesn't matter very much: calls to these functions put
the parameters in the usual places anyway, and (with the exception of
varargs) things just work.

However, the ELFv2 ABI on ppc64 optimises stack allocation
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html): a call to a
function that has a prototype, is not varargs, and receives all parameters
in registers rather than on the stack does not require the caller to
allocate an argument save area.  The incorrect prototypes cause GCC to
believe that all functions declared this way can be called without an
argument save area, but if the callee has sufficiently many arguments then
it will expect that area to be present, and will thus corrupt the caller's
stack.  This happens in particular with calls to runInteractiveProcess in
libraries/process/cbits/runProcess.c.

The simplest fix appears to be to declare these external functions with an
unspecified argument list rather than a void argument list.  This is no
worse for platforms that don't care either way, and allows a successful
bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2
ABI).

Fixes #8965

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>
Add the powerpc64le architecture

This is ArchUnknown for now, as it requires some porting work over and
above powerpc64 due to such things as the different function calling
sequence in the ELFv2 ABI.  For now, an unregisterised port is better
than nothing.

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>
Separate thousands when printing allocated bytes

When printing allocated bytes (`:set +s` in ghci), separate thousands
to make it easier to read large allocations sizes, e.g. “1,200,000
bytes”.

Signed-off-by: Austin Seipp <austin@well-typed.com>
Fix `make help`

Signed-off-by: Austin Seipp <austin@well-typed.com>