Ticket #793 (closed task: fixed)

Opened 2 years ago

Last modified 2 months ago

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

Reported by: simonmar Assigned to: simonmar
Priority: normal Milestone: 6.10.1
Component: Runtime System Version: 6.4.1
Severity: normal Keywords:
Cc: pho@cielonegro.org Difficulty: Moderate (1 day)
Test Case: N/A Architecture: Unknown
Operating System: Unknown

Description

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.

Change History

10/20/06 15:15:14 changed by igloo

  • testcase set to N/A.
  • owner set to igloo.
  • milestone set to 6.6.1.

10/20/06 16:48:13 changed by 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.

10/21/06 07:14:36 changed by 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/

11/17/06 07:06:00 changed by simonmar

  • priority changed from normal to low.

03/27/07 16:48:03 changed by igloo

  • priority changed from low to normal.
  • milestone changed from 6.6.1 to 6.8.

Punting on this

11/12/07 05:44:29 changed by simonmar

  • owner deleted.

01/03/08 08:47:13 changed by simonmar

  • owner set to 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.

(follow-up: ↓ 9 ) 01/03/08 08:57:31 changed by 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.

(in reply to: ↑ 8 ) 01/04/08 06:30:16 changed by 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.

06/17/08 17:22:10 changed by PHO

  • cc set to pho@cielonegro.org.

06/20/08 15:23:49 changed by igloo

  • milestone changed from 6.8 branch to 6.10.1.

06/23/08 08:10:33 changed by simonmar

  • status changed from new to closed.
  • resolution set to fixed.

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