Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?

[simonmar]

libffi is a library that comes with gcc and provides FFI functionality (dynamic calls, closures) for a wide range of platforms. It has a liberal license that is compatible with GHC's.

libffi could replace Adjustor.c in the RTS and the ByteCodeFFI module in GHCi. The benefits would be:

• It works on more platforms than we currently support, and it handles more of the dark corners than we do (eg. struct returns?).

• It would ease the task of porting GHC

• Replaces a wad of very difficult non-portable code in GHC with code written and actively maintained by others.

On the other hand, it is possible that our Adjustor.c code is faster, because it is more specialised to the task.

[wolfgang]

Some counter-arguments to consider:

• Mac OS X/x86 is not supported (so unless we fix libffi, we need to keep Adjustor.c & ByteCodeFFI around anyway).

• libffi is maintained as part of gcj, not gcc itself and is therefore slightly less universal.

• libffi is only available as part of the GCC source distribution.

[Neil Mitchell]

The Yhc team use Python's ctypes, which is roughly the same thing as libffi, but works in more places (everywhere Python does), is a separate library so can be installed independantly, and also works on Windows with Visual Studio.

This might be a better choice than libffi, which we initially looked at and then rejected.

svn co  http://svn.python.org/projects/ctypes/trunk/ctypes/source/

[igloo]

Punting on this

[simonmar]

I have the createAdjustor part of this working, but it needs proper autoconf gubbins etc., and we need to decide whether to import libffi into our tree and hook it into the build system or not. Right now I'm compiling against the libffi supplied by Debian/Ubuntu, which appears to be close to the version in the gcc SVN repository.

[igloo]

I don't think we should bundle it. It's the sort of thing where more obscure platforms need the latest version, and we don't another thing we have to make sure we keep up-to-date. Also, for the common case (including Windows users) it isn't necessary to have it, as the existing code can be used instead.

[simonmar]

Replying to igloo:

I don't think we should bundle it. It's the sort of thing where more obscure platforms need the latest version, and we don't another thing we have to make sure we keep up-to-date. Also, for the common case (including Windows users) it isn't necessary to have it, as the existing code can be used instead.

I agree, except that I've just done a bit of digging and libffi would fix:

• #1288 (stdcall in GHCi on Windows)
• #738 (SELinux)
• #631 (FFI in GHCi unregisterised)

For #738, we could pinch the code from libffi which works around the issue (the license is unrestrictive). For #1288, I'd rather just use libffi than implement it myself, but that means requiring libffi on Windows. For #631, I assume it's not a problem to require libffi for unregisterised builds.

[simonmar]

This is now done, and we decided to keep Adjustor.c around for the time being but retire ByteCodeFFI. Regarding Wolfgang's reservations above, none of these are still relevant (libffi has a standalone distribution, and it supports MacOS X/x86).