arm tune files status summary

arm tune files status summary

[Phil Blundell]

There are quite a lot of different sub-threads going on at the moment
regarding the various breakages associated with the recent arm tuning
file patch.  Here's a summary of what I think are all the current issues
and their status.

1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
rootfs construction to fail.

Paul and Koen both posted (essentially identical) patches for this and
it looks as though Paul's has been applied.  So, the original breakage
should be resolved but it isn't entirely clear what this line in
bitbake.conf was trying to accomplish in the first place.  I think
someone still needs to conduct an audit to establish whether there are
any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
need setting to ${TARGET_ARCH} and, if so, make that happen.

2. endianness confusion in armv5/armv6 tune files.

I posted a patch for this.  It doesn't look like it's been applied yet
but it's in the archives for anybody who wants it.  Only big-endian
configs would be affected anyway and I think those are something of a
fringe pursuit.

3. eglibc unbuildable on qemuarm

This is happening because qemuarm selects arm926ejs tuning, which in
turn selects armv5te, and the current arrangement of tune files forces
Thumb-state on if you ask to tune for a T-variant architecture.  The old
"ARM_INSTRUCTION_SET" variable which used to override the ISA selection
seems not to be respected anymore.  This is unfortunate because there is
assembler code in eglibc which isn't Thumb-1 aware and hence can't be
built under -mthumb.

A short-term workaround would be to hack tune-arm926ejs.inc to select
the TUNE_FEATURES for armv5e rather than armv5te.  But this is clearly
not a good solution in general and, other than changing the underlying
policy of inferring ISA choice from architecture name, it's not obvious
what the right way of solving it is.

This particular issue causes sufficiently gross breakage that I would
have expected it to show up on the Yocto autobuilder run before the
patch was merged.  I'm not quite sure why it apparently didn't fail
there but maybe the autobuilder doesn't actually test qemuarm at
present.

4. can't build ARM-state code for ARMv4T architecture.

This is another facet of the above; there is currently no way to say
that you want to select -march=armv4t without also enabling -mthumb.
This makes it impossible to build interworking-capable ARM-state code
for v4T.

5. cortex tuning not working

Various of the cortex files had a spelling mistake which would cause the
TUNE_FEATURES never to actually match anything.  This is a trivial fix
and I sent a patch for it yesterday.  I don't think it's been merged
yet.

6. distros no longer able to select ARM vs Thumb state either globally
or per package

This is really another manifestation of the issue in #3.  But the point
here isn't so much that builds are failing, rather that we seem to have
lost the ability to have a single switch that the DISTRO can flip to
build the entire world (or individual packages) as Thumb rather than
ARM.  For Thumb-1 in particular the tradeoffs are sufficiently
complicated that I don't think there is ever going to be a globally
"right" answer.

I think that's all I know of.

p.

Re: arm tune files status summary

[Koen Kooi]

Op 29 jul. 2011 om 15:28 heeft Phil Blundell <philb@gnu.org> het volgende geschreven:

> There are quite a lot of different sub-threads going on at the moment
> regarding the various breakages associated with the recent arm tuning
> file patch.  Here's a summary of what I think are all the current issues
> and their status.
> 
> 1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
> rootfs construction to fail.
> 
> Paul and Koen both posted (essentially identical) patches for this and
> it looks as though Paul's has been applied.  So, the original breakage
> should be resolved but it isn't entirely clear what this line in
> bitbake.conf was trying to accomplish in the first place.  I think
> someone still needs to conduct an audit to establish whether there are
> any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
> need setting to ${TARGET_ARCH} and, if so, make that happen.
> 
> 2. endianness confusion in armv5/armv6 tune files.
> 
> I posted a patch for this.  It doesn't look like it's been applied yet
> but it's in the archives for anybody who wants it.  Only big-endian
> configs would be affected anyway and I think those are something of a
> fringe pursuit.
> 
> 3. eglibc unbuildable on qemuarm
> 
> This is happening because qemuarm selects arm926ejs tuning, which in
> turn selects armv5te, and the current arrangement of tune files forces
> Thumb-state on if you ask to tune for a T-variant architecture.  The old
> "ARM_INSTRUCTION_SET" variable which used to override the ISA selection
> seems not to be respected anymore.  This is unfortunate because there is
> assembler code in eglibc which isn't Thumb-1 aware and hence can't be
> built under -mthumb.
> 
> A short-term workaround would be to hack tune-arm926ejs.inc to select
> the TUNE_FEATURES for armv5e rather than armv5te.  But this is clearly
> not a good solution in general and, other than changing the underlying
> policy of inferring ISA choice from architecture name, it's not obvious
> what the right way of solving it is.
> 
> This particular issue causes sufficiently gross breakage that I would
> have expected it to show up on the Yocto autobuilder run before the
> patch was merged.  I'm not quite sure why it apparently didn't fail
> there but maybe the autobuilder doesn't actually test qemuarm at
> present.
> 
> 4. can't build ARM-state code for ARMv4T architecture.
> 
> This is another facet of the above; there is currently no way to say
> that you want to select -march=armv4t without also enabling -mthumb.
> This makes it impossible to build interworking-capable ARM-state code
> for v4T.
> 
> 5. cortex tuning not working
> 
> Various of the cortex files had a spelling mistake which would cause the
> TUNE_FEATURES never to actually match anything.  This is a trivial fix
> and I sent a patch for it yesterday.  I don't think it's been merged
> yet.
> 
> 6. distros no longer able to select ARM vs Thumb state either globally
> or per package
> 
> This is really another manifestation of the issue in #3.  But the point
> here isn't so much that builds are failing, rather that we seem to have
> lost the ability to have a single switch that the DISTRO can flip to
> build the entire world (or individual packages) as Thumb rather than
> ARM.  For Thumb-1 in particular the tradeoffs are sufficiently
> complicated that I don't think there is ever going to be a globally
> "right" answer.
> 
> I think that's all I know of.

This matches my observations, thanks for summarizing all this!



> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: arm tune files status summary

[Khem Raj]

On 07/29/2011 06:28 AM, Phil Blundell wrote:
> There are quite a lot of different sub-threads going on at the moment
> regarding the various breakages associated with the recent arm tuning
> file patch.  Here's a summary of what I think are all the current issues
> and their status.
>
> 1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
> rootfs construction to fail.
>
> Paul and Koen both posted (essentially identical) patches for this and
> it looks as though Paul's has been applied.  So, the original breakage
> should be resolved but it isn't entirely clear what this line in
> bitbake.conf was trying to accomplish in the first place.  I think
> someone still needs to conduct an audit to establish whether there are
> any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
> need setting to ${TARGET_ARCH} and, if so, make that happen.
>
> 2. endianness confusion in armv5/armv6 tune files.
>
> I posted a patch for this.  It doesn't look like it's been applied yet
> but it's in the archives for anybody who wants it.  Only big-endian
> configs would be affected anyway and I think those are something of a
> fringe pursuit.

I am testing this patch

>
> 3. eglibc unbuildable on qemuarm
>
> This is happening because qemuarm selects arm926ejs tuning, which in
> turn selects armv5te, and the current arrangement of tune files forces
> Thumb-state on if you ask to tune for a T-variant architecture.  The old
> "ARM_INSTRUCTION_SET" variable which used to override the ISA selection
> seems not to be respected anymore.  This is unfortunate because there is
> assembler code in eglibc which isn't Thumb-1 aware and hence can't be
> built under -mthumb.
>
> A short-term workaround would be to hack tune-arm926ejs.inc to select
> the TUNE_FEATURES for armv5e rather than armv5te.  But this is clearly
> not a good solution in general and, other than changing the underlying
> policy of inferring ISA choice from architecture name, it's not obvious
> what the right way of solving it is.
>
> This particular issue causes sufficiently gross breakage that I would
> have expected it to show up on the Yocto autobuilder run before the
> patch was merged.  I'm not quite sure why it apparently didn't fail
> there but maybe the autobuilder doesn't actually test qemuarm at
> present.

I have posted a patch for this

>
> 4. can't build ARM-state code for ARMv4T architecture.
>
> This is another facet of the above; there is currently no way to say
> that you want to select -march=armv4t without also enabling -mthumb.
> This makes it impossible to build interworking-capable ARM-state code
> for v4T.

yeah this is kind of fundamental problem. We need to differentiate 
between having thumb feature and really using it.
>
> 5. cortex tuning not working
>
> Various of the cortex files had a spelling mistake which would cause the
> TUNE_FEATURES never to actually match anything.  This is a trivial fix
> and I sent a patch for it yesterday.  I don't think it's been merged
> yet.

I am testing this patch

>
> 6. distros no longer able to select ARM vs Thumb state either globally
> or per package

My thinking is that default should always be ARM mode and then distros
can say TUNE_FEATURES += "usethumb" then tune infra can check for both
i.e. having thumb in machines and distros asking for it before adding
-mthumb to CCARGS
>
> This is really another manifestation of the issue in #3.  But the point
> here isn't so much that builds are failing, rather that we seem to have
> lost the ability to have a single switch that the DISTRO can flip to
> build the entire world (or individual packages) as Thumb rather than
> ARM.  For Thumb-1 in particular the tradeoffs are sufficiently
> complicated that I don't think there is ever going to be a globally
> "right" answer.
>
> I think that's all I know of.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core