Be less untruthful about the prototypes of external functions
authorColin Watson <cjwatson@debian.org>
Sat, 12 Apr 2014 00:55:07 +0000 (01:55 +0100)
committerAustin Seipp <austin@well-typed.com>
Tue, 22 Apr 2014 03:27:25 +0000 (22:27 -0500)
commit5a31f231eebfb8140f9b519b166094d9d4fc2d79
treeb351c89c4b0b707eea34a3bf3d228d9226f6a114
parentc29bf984dd20431cd4344e8a5c444d7a5be08389
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>
includes/Stg.h