r187174 - Fix GNU ObjC ABI for a message returning a struct.

John McCall rjmccall at apple.com
Mon Jul 29 13:24:49 PDT 2013

On Jul 29, 2013, at 12:10 PM, Jonathan Schleifer <js at webkeks.org> wrote:
> Am 29.07.2013 um 19:39 schrieb John McCall:
>> Okay, so this is the use case of a source-distributed library where the code author can’t actually just control the compiler?  Fair enough.  But yes, I think if you want to advertise this, you need to do it from your headers.
> Yes, advertising this from my headers was the idea from the start. The idea was to have a whitelist of architectures for which an assembly implementation of of_forward_stret exists and additionally check __has_feature(objc_msg_lookup_stret) to make sure that not only the runtime supports it, but also the compiler. If all those are true, a define is set.
>> This seems reasonable, but our supported version scheme is actually X.Y.Z.  You’re sure you’ll never want to use sub-minor releases?
>> Also, if you’re going to compare the __OBJFW_RUNTIME__ value, you need to pick a version for -fobjc-runtime=objfw.
> Oh, my impression was that the version is the ABI version, not the runtime version. The runtime version doesn't help me at all - that's something I know. What I do care about is the ABI version the compiler emits.
>> We’re not going to hardcode the ObjFW release history into the compiler. :)  You’d potentially have to patch us (and require a new compiler) every time you issued a new release, which is why we don’t sanity-check version numbers for anything else.  If you want to have this check in your headers (“targeting a new runtime version, but not using up-to-date headers?”), go ahead.
> Oh, it seems I completely got wrong what that version is. I thought -fobjc-runtime=objfw-0.1 means "Use the ObjFW runtime and use version 0.1 of the ABI", not "Emit code for the ObjFW runtime 0.1”.

Yeah, the version is the minimum version of the runtime the user wants us to target.  So, for example, if you add new runtime features in an ObjFW release (like this...), but the user asks us to target ObjFW v0.7, then we need to not use those runtime features.  Eventually, when we settled on the desired behavior here, I was going to ask you to do this.

> Anyway, what I need is a version of some kind that I can use to get the ABI version of the compiler. What I'd ideally like to have is just some define like __OBJFW_ABI_VERSION__ that I can increase by one from time to time when new features are added, so that a check like #if __OBJFW_ABI_VERSION >= 1 is sufficient. What would be the best way to do this if the version of the ObjCRuntime class is something else?

You could define a separate __OBJFW_COMPILER_VERSION__ that records the compiler’s target ObjFW version.  That would basically be the minimum of the last ABI revision you made in the compiler and the version from -fobjc-runtime.

So, assuming the compiler supports targeting ObjFW 1.2.5, you’d get these macros:

Under -fobjc-runtime=objfw:
  #define __OBJFW_VERSION__ 0x10205
  #define __OBJFW_COMPILER_VERSION 0x10205

Under -fobjc-runtime=objfw-2.0:
  #define __OBJFW_VERSION__ 0x20000
  #define __OBJFW_COMPILER_VERSION 0x10205

Under -fobjc-runtime=objfw-1.1.3:
  #define __OBJFW_VERSION__ 0x10103
  #define __OBJFW_COMPILER_VERSION 0x10103

Make sense?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130729/0e3115ad/attachment.html>

More information about the cfe-commits mailing list