[Top][All Lists]

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

Re: Which ObjC2.0 features are missing in the latest GCC?

From: David Chisnall
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Wed, 27 Nov 2019 11:02:58 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 26/11/2019 22:43, Fred Kiefer wrote:
If I understand you correctly your suggestion is that we try to add support in 
gcc for some of the basic ObjC 2.0 features. That should be doable although the 
last time I tried I gave up on it. That was right after the Dublin meeting 
where we had a similar discussion to this one. The gcc people at that time 
where open to accept patches, but we should not expect too much help coming 
from their side. The reason I gave up was that at least a new version of the 
meta information that the compiler creates for the ObjC meta information was 
needed and I could not figure out a place where to flag that difference.

Please can people stop saying 'Objective-C 2'? It's a marketing term that Apple used briefly and then dropped and has no relationship to any real definition of what the language means and does not appear on the Apple developer web site at all anymore.

Ian Sandoe was going to work on a better runtime abstraction layer for Objective-C in GCC. He said he'd work on this two years ago, but doesn't seem to have made much progress, though he has done a little bit of work on improving the state of Apple runtime support. His plan was to delay the runtime-specific lowering to the back end, which would be very nice and let LTO do some more interesting things.

Supporting a new ABI is much harder in GCC than Clang because of the history. In GCC, the initial implementation supported only the NeXT runtime. NeXT was forced to release this code via the threat of legal action and GCC was forced to merge the code to avoid looking stupid after forcing NeXT to release the code. It was horrible code and if NeXT had open sourced it without the threat of legal action, I doubt GCC would have accepted it upstream.

Because GCC had the NeXT compiler code but no runtime support, they wrote an almost-compatible runtime and littered the code with `if (gnu_runtime)` blocks (I think, it might be `if (next_runtime)`. NeXT / Apple never pulled in those changes and so merging from Apple's branch was always painful.

In contrast, Clang had no IR generation support when I started working on it. I added an abstract class representing the runtime interfaces and a concrete subclass for the GCC and GNUstep runtimes. Apple then maintained this because they were supporting various different runtime versions by this point and found the abstraction helpful.

Adding a new GCC-like runtime in clang involved simply creating a new subclass of this and overriding the things that had changed. For GCC, it will involve untangling a load of spaghetti code.

It's probably a few months of work for someone with GCC experience to add support for the 2.0 ABI, though it's quite tangled with ARC if you wan it to actually be useful (for example, ivar metadata contains ARC ownership metadata now, which allows various reflection APIs to work correctly with ARC).

This is one of the current problems with the 'GNUstep doesn't use ARC, but it's fine with other things that do' approach: if you don't use ARC, you don't get ARC metadata, so things that use reflection don't work quite right from ARC. You can't use weak properties from GNUstep. For several release on macOS, things like the delegate of various NSView subclasses have been weak properties. This means that modern Cocoa apps don't worry about ensuring that the delegate is removed from the view, they just rely on the runtime to handle this for them.

In GNUstep, if we wanted to depend on an ARC-supporting runtime but not compiler, then we *could* manually write the -setDelegate: and -delegate methods to call the relevant ARC functions, but:

- The ivar would not be __weak and so access via reflection would break it.

- The property metadata would not exist, so anything that depends on property metadata would break.

Modern Cocoa APIs are written assuming ARC and involve sublcassing classes that are expected to be compiled with ARC. Over time, the work-arounds for the fact that GCC fundamentally does not support the same language that Cocoa was designed to work with are increasingly creaky.

TL;DR: Even with support for the new ABI, you still can't implement a fully Apple-compatible NSTableView and compile it with GCC.


reply via email to

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