Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: Andre McCurdy <armccurdy@gmail.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5
Date: Thu, 03 Mar 2016 13:02:35 +0000	[thread overview]
Message-ID: <1457010155.3476.31.camel@pbcl.net> (raw)
In-Reply-To: <1453937316-1311-4-git-send-email-armccurdy@gmail.com>

On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
> -ARM_INSTRUCTION_SET = "arm"
> +ARM_INSTRUCTION_SET_armv4 = "arm"
> +ARM_INSTRUCTION_SET_armv5 = "arm"

Although I agree that this is a net improvement over the old code in
almost all cases, this patch is not quite right.  The reason for the
original override is that there is assembler code in glib which won't
compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only available
in ARMv6T2 and newer architectures so with your patch it looks like
compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now fail.

I recommend that we either:

1. Introduce a new, explicit "thumb1" override which can be enabled by
the appropriate arch-arm*.inc files, and make all the appropriate
recipes set ARM_INSTRUCTION_SET based on that; or

2. Introduce a new thumb1-compatible.inc file which contains lines like

ARM_INSTRUCTION_SET_glib-2.0 = "arm"

and let distros which want to support older ARMs and enable Thumb
include that file; or

3. Take the view that it's now nearly fifteen years since Thumb-2 was
introduced, OE-core no longer needs to pander explicitly to Thumb-1,
and we should just remove all this scar tissue entirely.  Distros that
do want to target Thumb-1 can still maintain the appropriate
compatibility stuff (which is probably only a dozen lines or so) for
themselves.

Personally I would favour #3. :-)

p.



  reply	other threads:[~2016-03-03 13:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 23:28 [PATCH 0/3] glib-2.0: minor fixes and updates Andre McCurdy
2016-01-27 23:28 ` [PATCH 1/3] glib-2.0: refresh configure-libtool.patch Andre McCurdy
2016-01-27 23:28 ` [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch Andre McCurdy
2016-02-01 22:23   ` Randy MacLeod
2016-02-01 22:44     ` Phil Blundell
2016-02-03  8:07       ` Huang, Jie (Jackie)
2016-01-27 23:28 ` [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5 Andre McCurdy
2016-03-03 13:02   ` Phil Blundell [this message]
2016-03-03 13:18     ` Martin Jansa
2016-03-03 14:00       ` Phil Blundell
2016-03-03 19:11         ` Andre McCurdy
2016-03-03 19:30           ` Phil Blundell

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=1457010155.3476.31.camel@pbcl.net \
    --to=pb@pbcl.net \
    --cc=armccurdy@gmail.com \
    --cc=openembedded-core@lists.openembedded.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