About libffi on amd64:
----------------------

The purpose of this port is to support jamvm-1.4.2 on amd64.

This port is based on libffi in gcc-4.1, per recommendations of the author.
The distribution file we are using is a free-standing extract from
gcc 4.1 (which is very large indeed.)

On the amd64 the implementation of gcc-3.3.5 and libffi passes the 
ffitest.c sanity checks.  Additionally, jamvm works too.  QED.

About libffi on i386:
---------------------

First off, jamvm does not require libffi on the i386.

But libffi fails it's ffitest.c on the i386 because of a subtle non-conforming
implementation of OpenBSD's gcc-3.3.5 when returning struct results. One kind
of failure looks like this:

struct troublesome {
  float f;
  int i;
};

struct troublesome test3(struct troublesome ts) {
  // do some calculation based on ts
  return ts;
}

The specific problem with gcc-3.3.5 (and possibly later) is that the
float within the struct is passed as a double, meaning that 12 bytes are
passed in this case, but the return value is copied with
sizeof(ts) == 8, meaning that the int is not copied into the result
(the second word of the double is copied instead.)
This kind of issue (it happends for other small types) causes several
tests to fail.

This defect does not appear in the amd64 implementation of gcc-3.3.5

This in practice is probably far less serious of an issue than one might think.
Appearantly the troublesome construct is never used in all of the OpenBSD
source itself (for otherwise it would have most certainly been fixed by now.)
However, it is a defect and therefore libffi must be considered broken
for i386 based on this technicality.

Thus, contrary to urban legend, libffi test failures have nothing to do
with propolice and everything to do with an unpatched bug in gcc code
generation.

In both architectures, OpenBSD's W^X page protection affects the
trampoline implementations; a patch for this is in this version of ffitest.c

Fred Druseikis
5/30/2006
