On 08/14/2014 12:32 AM, Khem Raj wrote:
On Wed, Aug 13, 2014 at 6:55 PM, Peter A. Bigot <p...@pabigot.com> wrote:
EXTRA_OECONF += '${@bb.utils.contains("TUNE_FEATURES", "armv7a",
"--with-cpu=generic-armv7-a", "", d)}'
Sorry a typo there you need --with-arch
OK, that works. So do we need to do the same thing for every TUNE_FEATURES
element that ends up changing the value of -march= in TUNE_CCARGS which ends
up getting passed into gcc-runtime?
Not really but arm v6+ is an exception here due to reasons explained
earlier. gcc as a target package is a bit
different than rest of them since it has mind of its own when it comes
to configuring it. It encodes certain
defaults into its driver etc. based on the configure parameters.
Ideally when we pass the flags via CFLAGS
it does it for most of packages but not for gcc.
tl;dr: the proposed fix to gcc-target works for my example but I'm
concerned it's a bandaid that doesn't address a more long-term risk.
I understand gcc-target is different. I frame the issue as: bitbake
(via toolchain-scripts.bbclass) ensures OE builds its applications with
TARGET_CC_ARCH flags such as -march=FOO, but building gcc itself
requires EXTRA_OECONF to pass different flags such as --with-arch=FOO
which set the default behavior for the target compiler.
There are actually a bunch of these gcc configuration options:
--with-schedule=cpu
--with-arch=cpu
--with-arch-32=cpu
--with-arch-64=cpu
--with-tune=cpu
--with-tune-32=cpu
--with-tune-64=cpu
--with-abi=abi
--with-fpu=type
--with-float=type
all of which affect the default for the corresponding -m flags, and any
of which may affect each other within gcc's configure script.
It sounds like the intent is that the default behavior of the target gcc
should match what bitbake is passing via TARGET_CC_ARCH. Of course, if
that were guaranteed there wouldn't be any need for OE to apply
TARGET_CC_ARCH at all, but I wouldn't suggest changing that.
My concern is that gcc-runtime invokes configure in subdirectories of
gcc's source tree, bypassing the top-level configure where some of the
translation from (e.g.) --with-arch=FOO to -march=FOO is done. It then
builds the libraries with TARGET_CC_ARCH flags appended to CC, CXX, and CPP.
What this means is that the libraries built by gcc-runtime use
TARGET_CC_ARCH settings that don't necessarily match the target
compiler's defaults, and that ABI conflicts can result by linking in
those libraries when the non-default settings were absent in non-OE
application builds. ABI can only be "guaranteed" if every one of the
-mFOO=BAR passed in TARGET_CC_ARCH (*or defaulted by the compiler*) has
a corresponding -with-FOO=BAR option passed to (*or inferred by*) gcc's
configure.
That's a pretty strong assumption to make.
It may be that this can be worked around for the specific case I raised
by explicitly adding --with-arch=armv7-a to gcc-target's EXTRA_OECONF. I
do have to wonder whether the same should be done for any of armv7
armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc which are other
-march options that are armv6+, and whether there are other ABI issues
that might be hiding now or in the future because TARGET_CC_ARCH makes
more assumptions than gcc-target does.
The solution I propose is to rework gcc-runtime's override of CC/CXX/CPP
so the libraries are built the same way they would be if they had been
built during gcc-target.
From initial attempts this won't be easy to do. I'd be happy to keep
trying if this worries other people, but if I'm being too picky I'll
just suck it up and move on.
Peter
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
