Re: GCC 3.4 / libobjc / mframe issues

[David Ayers]

David Ayers wrote:
> Hello everyone,
>
> so here's my current scoop on the situation:

[snip]

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

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:
   NSArgumentInfo
   -argumentInfoAtIndex: (not part of Cocoa)
   public GNUstep extensions:
   -methodInfo

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.

Cheers,
David