Commit 5a31f231 authored by Colin Watson's avatar Colin Watson Committed by Austin Seipp
Browse files

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

): 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

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

Fixes #8965
Signed-off-by: default avatarColin Watson <>
Signed-off-by: default avatarAustin Seipp <>
parent c29bf984
......@@ -213,7 +213,7 @@ typedef StgFunPtr F_;
#define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8))
#define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void)
#define FN_(f) StgFunPtr f(void)
#define EF_(f) extern StgFunPtr f(void)
#define EF_(f) extern StgFunPtr f()
/* -----------------------------------------------------------------------------
Tail calls
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment