gnustep-dev
[Top][All Lists]
Advanced

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

Re: GCC 4.x and ObjC/ObjC++ type encodings


From: David Ayers
Subject: Re: GCC 4.x and ObjC/ObjC++ type encodings
Date: Wed, 20 Jul 2005 22:36:04 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Ziemowit Laski wrote:
> As some of you may have noticed, the Objective-C method signature, 
> instance variable and type encodings (including @encode expressions)
> have changed between GCC 3.X and GCC 4.X series of compilers. The GCC
> 4.X implementation, although suffering from a couple of bugs, is
> nevertheless an improvement over the previous schemes in that it is 
> more orthogonal, and handles ObjC qualifiers (e.g., 'bycopy',
> 'inout') in a more canonical fashion (though further improvements are
> certainly possible).

> Thing is, it turns out that this encoding rewrite has caused quite a
> bit of pain in the Apple/Darwin world :-(. As a result, I'm presently
> working on a patch (which will go into apple-local-200502-branch for
> now) that will make GCC 4.X encodings match (to the extent possible)
> what Apple's GCC 3.3 did. This is neither pretty nor intellectually
> satisfying, but is nonetheless necessary to preserve
> release-to-release binary compatibility for the NeXT runtime.

> However, this requirement may or may not hold for the _GNU_ runtime, 
> which is why I'm writing this e-mail. Have folks in the GNU ObjC
> world experienced problems with the encoding changes between GCC 4.x
> and earlier versions? Would it be OK for the GNU runtime to go back
> to GCC 3.x encodings? (Doing so would clearly be easier for me :-) ).
> If not, could someone come up with a collection of
> GNU-runtime-specific test cases that capture what the desired GNU
> encodings are, so that I don't break you guys once I start
> integrating my encoding changes back into mainline in the future?

I think it would be great it we had some clarification on the intended
semantics of the encoding schemes.  To do that we should look at

a) in FSF GCC 3.3
b) in FSF GCC 3.4
c) in FSF GCC 4.0
d) and define what we really want

(I don't think that there was intended change wrt encoding/message
signatures between b-c but I think the logs showed an ordering issue wrt
bycopy out.)

I'm not sure about the apple runtime but for the GNU runtime the method
signature version
a) included platform specific information on argument/return values wrt
the calling conventions on that platform. (PS: I think you needed a
non-x86 platform like SPARC to actually see the extra notation.)
b) already included the change you are referring to in:
c) in which this information is not generated anymore.
   (There may have not been a GCC 3.4 from Apple which explains why you
only mention 3.3 and 4.0.)

But I'm not clear about what the intended changes were other than the
one you have mentioned (i.e. handle qualifiers like (oneway, in, out,
inout, bycopy, byref).

More specifically, what do you mean by:
- more orthogonal
- more canonical fashion

And what which part do you intend to revert, the qualifiers?

I've started on some test cases but beware they are WIP and I still yet
have to figure out how to make them portable as signatures are platform
dependent.  We (GNUstep) used to use the information provided by the
method signature do help us implement forwarding and possibly DO but
currently rely on libffi/ffcall.  I suppose that is the reason that GCC
3.4 did not cause great breakage wrt GNUstep.  Yet we did have fallout
on architectures like NetBSD on SPARC in some of our signature
validation code.

For reference I've attached not only the test cases but some log files for:

i686-pc-linux-gnu FSF GCC 3.3.6
i686-pc-linux-gnu FSF GCC 3.4.4
i686-pc-linux-gnu FSF GCC 4.0.1

sparc-sun-solaris2.7 FSF GCC 3.4.2

Cheers,
David

Attachment: enc_sig.tar.gz
Description: GNU Zip compressed data


reply via email to

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