public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
Date: Thu, 30 Sep 2021 11:49:12 +0000	[thread overview]
Message-ID: <bug-102537-4-dGjM76li7s@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102537-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-09-30
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Matt Jacobson from comment #0)
> I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin
> platform (AVR micros).  I'd like my Objective-C code to make use of the most
> modern ABI features, namely those guarded in the code by `flag_next_runtime
> >= USE_FIXUP_BEFORE`.
> 
> However, there appears to be no way to control `flag_next_runtime` (short of
> modifying the compiler source).  I can set it to zero with `-fgnu-runtime`
> or one with `-fnext-runtime`, but `USE_FIXUP_BEFORE` is an encoded Mac OS X
> version (namely 100600, referring to Snow Leopard).

by current design, there are enough bits in the value so that ne can have N
MSBs representing the platform and N representing the version.

> There is Darwin-specific option parsing code (`darwin_override_options()`)
> that appears to set `flag_next_runtime` based on `-mmacosx-version-min`, but
> obviously that doesn't run for non-Darwin targets.

Most targets have an equivalent "override options" section where they could
make a similar selection.

A simplistic case would be to say any value >990000 is not Darwin (i.e we make
the Darwin platform part of the runtime value == 0 and then any other platform
that wants to take an encoding takes a value higher; this would default to the
next runtime just using "latest and greatest" - but that might not be what you
want in say 2 years time...

... however, it would be better to use bit boundaries rather than arbitrary
decimal.

maybe ...
0xff000000 masks the platform 
0x00ffffff masks the version selector

and Darwin is platform 0 for this purpose.

so as a quick fix you could just say AVR is platform 1 and set it to 
0x01000000 in your platform flags override ...

> I could imagine a few approaches to fixing this:
> 
> 1. Parse `-mmacosx-version-min` even when the target is not Darwin, whenever
> we're compiling Objective-C.  On non-Darwin, this would be interpreted as
> requesting Objective-C codegen compatible with the Objective-C ABI of the
> specified release of Mac OS X.

I do not think that is going to fly ;)

> 2. Allow an argument to `-fnext-runtime`, with the meaning approximately the
> same as in #1.
> 
> 3. Instead of using `flag_next_runtime` as a version number, switch it back
> to being zero or one, and use a separate flag (perhaps the existing
> `-fobjc-abi-version`?) to differentiate ABIs.

These two were both thoughts during the development but I suspect that the
mapping to values is a build-time decision and ought to be done in the flags
override code.

thoughts?

  reply	other threads:[~2021-09-30 11:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  4:15 [Bug objc/102537] New: Objective-C: can't use >= USE_FIXUP_BEFORE paths for non-Darwin mhjacobson at me dot com
2021-09-30 11:49 ` iains at gcc dot gnu.org [this message]
2021-10-18 16:48 ` [Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin mhjacobson at me dot com
2022-05-06  8:31 ` jakub at gcc dot gnu.org
2022-05-07 13:44 ` egallager at gcc dot gnu.org
2023-05-08 12:22 ` rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-102537-4-dGjM76li7s@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).