[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC 3.4 / libobjc / mframe issues

From: David Ayers
Subject: Re: GCC 3.4 / libobjc / mframe issues
Date: Tue, 17 Aug 2004 23:18:11 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

David Ayers wrote:
Hello everyone,

so here's my current scoop on the situation:


Instead, my suggestion is to s/NSWarnLog/NSDebugLog/ the warnings about
changed method signatures in -base before the release as these will pop
up sooner or later when more people mix gcc < 3.4 and 3.4+ code.  It's
already pestering folks who's mframe code doesn't match gcc signature
(e.g. hppa/linux, SPARC/Solaris).  (Actually I know of no platform where
it always matches, it just so happens to match most signatures on common
archs.  But I'd be interested in archs that actually pass the
Testing/nsmethodsignature test I committed this week.)

For platforms that have negative offsets (where libobjc will bailout),
I'd suggest updating to gcc 3.4.x.

After the release we should consider removing the mframe code and
signature manipulation, as any effort put into resurrecting mframe for a
given arch is probably better invested in libffi/ffcall support for that

I've now tried to play with --disable-ffi --disable-ffcall --disable-do and all my tests (incl. Testing/nsinvocation) indicate that NSInvocation is broken as soon as you use structs (and NS_MESSAGE and NS_INVOCATION macros also).

I've had several private conversations (esp. w. Richard) and the sum of it seems to be that we could:

-- remove sanity checks wrt the layout information in method signatures
-- deprecate --disable-do and require either ffi or ffcall
-- deprecate some of the NSMethodSignature methods
   part of OpenStep:
   -argumentInfoAtIndex: (not part of Cocoa)
   public GNUstep extensions:

I believe this to be an option only because these methods currently return unreliable information so I can't imagine anything actually relying on it. But maybe it works on some platforms, so I would really appreciate some feedback if anyone is using this.

We would temporarily keep the mframe code so we can send the buggy layout information in signatures for DO so that older systems won't crash at the new layout of gcc. We can stop sending that info later and have 2.1 work with 2.0 which doesn't have the sanity checks but it will not be able to talk to 1.9 which still has them. At that point we can start looking at what we can kick out.

Adam, is this the only thing holding back the release or are you also waiting on the GNUstep.sh issue as it seems to be something worth 2.0 also.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]