Re: ffcall on Darwin/PPC

[David Ayers]

Andrew Pinski schrieb:
> On 3/17/07, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:
> 
>> I do not see how this could ever be fixed, so I'm
>> inclined to think that GNUstep should drop libffi.
> 
> 
> You know I have not see any bug reports from you about libffi.  In
> fact I rather have GNUStep always use libffi because it is more
> supported with more targets (and the semi official base code is inside
> GCC).  I am about to review the patch which used libffi instead of
> __builtin_apply (etc.) inside libobjc also.
> 

I tend to agree with Andrew.  I have tried to contact ffcall maintainers
for issues in either SPARC or NetBSD architectures and haven't had
productive responses.

IIRC, building the development environment for ffcall entails
non-portable configure scripts and specific gcc versions (2.7.?).

The problem is that both libffi and ffcall solve non-trivial problems
and /I/ haven't been able to easily find the documentation needed to
use/fix them...  which makes formulating useful bug reports also
non-trivial.

But realize that libffi is what gcc's java implementation uses so for
the common platforms I believe the issues don't necessarily lay within
libffi.

I do remember that with respect to method signatures we rely on what gcc
encodes.  So we may simply need gcc support to ensure that methods that
are implemented yet not declared are encoded.  But IIRC that's just the
tip of the iceberg.  When Apple merged its 'ObjC improvements' into gcc
they "simplified" the previously platform specific method signature
encodings and now we are missing or using misleading information for
some ABI's.

This just emphasizes the fact that GNUstep should not really depend on
either libffi nor ffcall for message forwarding or signature
en/decoding, but that this should be encapsulated in libobjc.  And gcc's
test suite should include appropriate tests for all platforms we care about.

I once started writing signature encoding tests, but it's a non-trivial
task to write portable tests when the current signature generation is
broken, and it fell off my radar.

But in principal I think the correct direction is to
- implement forwarding in libobjc
- write gcc/libobjc tests for the platforms we care about
- run (automated) gcc/libobjc regression tests for the platforms we care
about
- use libobjc for message forwarding in GNUstep

The only issue I see here is that I don't know whether Apple's libobjc
implements a forwarding API for Darwin based distributions which may be
using Apple's runtime.  OTOH, I don't know how useful Apple's current
runtime is without Apple's Foundation as IIRC the runtime delegates much
of it's work to (Core?)Foundation, but I haven't really investigated it
deeply, not owning a Mac.

Cheers,
David