gnustep-dev
[Top][All Lists]
Advanced

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

Re: GNUstep base almost builds with clang


From: David Chisnall
Subject: Re: GNUstep base almost builds with clang
Date: Tue, 31 Mar 2009 17:49:27 +0100

On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:

On 30 Mar 2009, at 16:37, David Chisnall wrote:

NSInvocation.m provides default implementations in terms of __builtin_apply() and friends that are not used when libffi or ffcall is provided. Is it possible to move these into a separate concrete subclass of NSInvocation along the lines of GSFFIInvocation/GSFFCallInvocation and only compile them when no better mechanism is provided?

I should think that's not only possible, but a very good idea.

Great news.

I *think* (iirc) a little of the code in mframe is used for some NSMethodSgnature features. It may be that we always need that part compiled in, but it should be possible to separate out what we need, and only build the rest of the code if we don't have libffi or ffcall.

Using the power of grep, I see:

NSMethodSignature uses some mframe stuff for parsing type encodings. This doesn't really make sense being in mframe.m, since it's nothing to do with creating call frames.

NSConnection uses them in -forwardForProxy:selector:argFrame:, which I believe is deprecated since all of the argframe stuff was deprecated years ago and never worked correctly, and in a few places with #ifdefs so they're not actually compiled.

NSInvocation.m uses them in the fall-back code for when ffcall and libffi are not present.

NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment().

The stuff for decoding type strings should probably be pulled into a separate file.

objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()?

I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways.

This function seems to be part of an attempt to reproduce the old NeXT runtime API. More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here:

http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/

At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs are going to start using it.

David

[1] If possible, I'd like to keep the MIT license for these files so they can be easily used outside of GNUstep as well, since they are low- level and have potential applications for Objective-C code that does not use GNUstep.




reply via email to

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