[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ffcall on Darwin/PPC
From: |
Wolfgang Lux |
Subject: |
ffcall on Darwin/PPC |
Date: |
Sat, 17 Mar 2007 19:36:47 +0100 |
Hello,
the recent change in gnustep-base and gnustep-startup to check whether
ffcall trampolines work did remind me that I've been running GNUstep
with ffcall instead of libffi on Darwin/PPC for quite a while without
problems now. I've attached two small patches that make the trampoline
test pass on Darwin/PPC, too (gcc on Darwin/PPC defines __ppc__ or
__ppc64__ instead of __powerpc__), and make ffcall the default on
Darwin/PPC as it is on other targets.
The main reason for this change is that libffi has a serious problem
with message forwarding if the signatures of the forwarded methods
are omitted. See this message:
http://lists.gnu.org/archive/html/discuss-gnustep/2006-04/msg00107.html
and the ensuing short thread.
In fact, I had a little closer look at the issue and the problem is
in function gs_objc_msg_forward in GSFFIInvocation.m. This function
is invoked from the Objective-C runtime when a method selector is not
implemented by the receiver of a method call. If the compiler cannot
determine the signature of the called method, which happens if the
receiver's class does not declare the method, gs_objc_msg_forward uses
the fixed signature of a method with no arguments and an id result. The
signature is then used to copy the method arguments into a malloc'ed
buffer. Obviously, no arguments are copied at all in this case and
hence the target of the forwarded method call will be called with
undefined arguments. I do not see how this could ever be fixed, so I'm
inclined to think that GNUstep should drop libffi.
Regards
Wolfgang
P.S.: Just for the record, I'm using FSF Gnu C 4.1.1 and ffcall 1.10.
startup.patch
Description: Binary data
base.patch
Description: Binary data
- ffcall on Darwin/PPC,
Wolfgang Lux <=