[OE-core] qemuarm: should it really have TUNE_ARCH armv5te?

[Phil Blundell]

On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote:
> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs?

That's a DISTRO policy decision really.

"armv5te", in common with most of the PACKAGE_ARCHes, represents an ISA.
That is, it is guaranteed to only contain instructions which are
supported by all v5TE cores (which includes both ARM926EJ-S and XScale).
It obviously follows from this that packages with PACKAGE_ARCH=armv5te
are suitable for running on both qemuarm and xscale MACHINEs.

Note that a binary that was built with -mtune=arm926ej-s is still an
ARMv5TE binary and will run just fine on xscale.  It won't run quite as
fast as one that was built -mtune=xscale, though the performance
difference is not so great as to be completely crippling.  With current
gcc, the reverse is true as well: a binary built -mtune=xscale is also
still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the
performance penalty is less this way around.

Now, if your DISTRO feels that the performance difference is important
enough to be worth distinguishing the packages, you can certainly
arrange for those two tunings to get separate PACKAGE_ARCHes and
maintain parallel feeds.  But in the general case it's not totally
obvious that this would be worthwhile, and I'm not sure it is a very
useful thing to do by default.

p.