On May 14, 2012, at 12:20 PM, Jonathan Schleifer wrote: > Am 14.05.2012 um 21:12 schrieb John McCall: >> I agree that this is at least theoretically independent of the fragile ABI >> vs. the nonfragile ABI, although I suspect that you'd need to check both >> implementations to verify that they do, in fact, guarantee the correctness >> of this. > > Well, not only theoretically: The GNUstep runtime uses the non-fragile ABI, > while my runtime currently uses the fragile ABI (I wanted to be compatible to > GCC and didn't have the time yet). > > What I do is that in the configure of my runtime I check if > -fobjc-direct-class-refs is accepted by Clang and if so use it and then later > output it when the runtime is queried for the OBJCFLAGS to compile with. > >> In Darwin's runtime, at least, the nonfragile ABI reserves the right to make >> class references "forward", so that the address of the global symbol is not >> necessarily the address of the class. > > Yes, but should this really be tied to the non-fragile ABI? IMHO even a ABI > version would make more sense than saying "non-fragile ABI also means direct > class references". This would also mean that we break existing stuff: > Currently, the non-fragile ABI does not emit direct-class refs. If it > suddenly would, I'm sure stuff will break.
On Darwin, the "fragile ABI" is really a completely different runtime with its own metadata layouts, entrypoints, etc. The GNU fragile and nonfragile runtimes are much more closely related, but the difference still implies more than just object layouts. I would be much happier if the "runtime"-selecting and "ABI"-selecting switches were combined, but that ship has sailed and we have to maintain compatibility. That is part of why I am very reluctant to compound the problem by adding new flags for every new thing which really ought to be implied by something else. Regardless, I did not bring up fragile vs. non-fragile ABIs, and I certainly never implied that this should be tied to that flag. >> Or, you know, it could be a subclass that just implements GetClass >> differently, or even just sets a flag in the common GNU implementation that >> is honored by GetClass. There is no need to leap to the most absurd >> possible implementation. >> >> The right thing to do is to propagate information down like "please optimize >> for this specific runtime". Whether that means "-fgnustep-runtime" or >> "-fgnu-runtime=gnustep" or "-foptimize-runtime=gnustep" is a separable >> choice. > > We would also need to specify the version, as an old version of the runtime > can be lacking a feature. Features like "it is legal to emit class references as direct symbol references"? That seems like a pretty broad guarantee which a runtime either does or does not provide. But yes, in principle it makes sense to write something like -fgnu-runtime=gnustep-1.0. > So, what I'm looking for is a solution that could get upstream and won't > require the user to do anything, so that my configure could just check if > Clang supports it and if so use it. I have no problem with providing some way to get the compiler to emit direct references. I just don't want it to be a command-line option. There are already too many different command-line options controlling the ObjC dialect. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
