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>