* [PATCH] gcc-common: Only apply fpu settings to target gcc @ 2014-05-01 15:40 Richard Purdie 2014-10-27 19:54 ` Kristof Robot 0 siblings, 1 reply; 6+ messages in thread From: Richard Purdie @ 2014-05-01 15:40 UTC (permalink / raw) To: openembedded-core Within the OE build environment, we supply the correct fpu settings. These only need to be spelt out for the on-target gcc. Doing this means the checksums for the core compiler don't depend on the fpu settings. We exclude the compiler tunes for similar reasons, it doesn't need to influence the compiler build. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc index 0408e65..e56e598 100644 --- a/meta/recipes-devtools/gcc/gcc-common.inc +++ b/meta/recipes-devtools/gcc/gcc-common.inc @@ -63,7 +63,7 @@ def get_tune_parameters(tune, d): retdict['package_extra_archs'] = localdata.getVar('PACKAGE_EXTRA_ARCHS', True) return retdict -get_tune_parameters[vardepsexclude] = "AVAILTUNES" +get_tune_parameters[vardepsexclude] = "AVAILTUNES TUNE_CCARGS" DEBIANNAME_${MLPREFIX}libgcc = "libgcc1" diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc index 3cb6ec8..31e3cc4 100644 --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc @@ -61,7 +61,7 @@ EXTRA_OECONF_append_libc-uclibc = " --enable-__cxa_atexit" EXTRA_OECONF_append_mips64 = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64" EXTRA_OECONF_append_mips64el = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64" -EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}" +EXTRA_OECONF_FPU ??= "" CPPFLAGS = "" # powerpc needs this to comply with the ABI diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index 45a1637..de906d6 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -7,6 +7,8 @@ EXTRA_OECONF_PATHS = " \ --with-native-system-header-dir=${STAGING_DIR_TARGET}${target_includedir} \ --with-gxx-include-dir=${includedir}/c++/" +EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}" + PACKAGES = "\ ${PN} ${PN}-plugins ${PN}-symlinks \ g++ g++-symlinks \ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc-common: Only apply fpu settings to target gcc 2014-05-01 15:40 [PATCH] gcc-common: Only apply fpu settings to target gcc Richard Purdie @ 2014-10-27 19:54 ` Kristof Robot 2014-10-27 22:59 ` Richard Purdie 0 siblings, 1 reply; 6+ messages in thread From: Kristof Robot @ 2014-10-27 19:54 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core Richard, all, After bisecting, I found that, since this patch, my toolchain is being built with soft floating point support, while it should be built with hard floating point support: (1) Compiling parent commit 74d8866814aec520822518cc4cb8a942f7069bf7 [1] gives hard floating point support (good): $./build.good74d8/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i SOFTFP $ (2) Compiling with this patch (commit ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf [2]) gives soft floating point support (bad): $ ./build.badce1f/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i SOFTFP #define __SOFTFP__ 1 $ I am using DEFAULTTUNE = "cortexa7hf-neon-vfpv4", resulting in following build configuration parameters: TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard vfpv4 cortexa7" TARGET_FPU = "vfp-vfpv4-neon" I can fix this by reverting the changes to meta/recipes-devtools/gcc/gcc-configure-common.inc, i.e.: --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc @@ -61,7 +61,7 @@ EXTRA_OECONF_append_libc-uclibc = " --enable-__cxa_atex EXTRA_OECONF_append_mips64 = " --with-abi=64 --with-arch-64=mips64 --with-tu EXTRA_OECONF_append_mips64el = " --with-abi=64 --with-arch-64=mips64 --with- -EXTRA_OECONF_FPU ??= "" +EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}" CPPFLAGS = "" S = "" Would that indeed be the correct way to fix this issue, or am I missing something? Thanks! Kristof [1] https://github.com/openembedded/openembedded-core/commit/74d8866814aec520822518cc4cb8a942f7069bf7 [2] https://github.com/openembedded/openembedded-core/commit/ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf On Thu, May 1, 2014 at 5:40 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > Within the OE build environment, we supply the correct fpu settings. These > only need to be spelt out for the on-target gcc. > > Doing this means the checksums for the core compiler don't depend on the fpu > settings. We exclude the compiler tunes for similar reasons, it doesn't need > to influence the compiler build. > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc > index 0408e65..e56e598 100644 > --- a/meta/recipes-devtools/gcc/gcc-common.inc > +++ b/meta/recipes-devtools/gcc/gcc-common.inc > @@ -63,7 +63,7 @@ def get_tune_parameters(tune, d): > retdict['package_extra_archs'] = localdata.getVar('PACKAGE_EXTRA_ARCHS', True) > return retdict > > -get_tune_parameters[vardepsexclude] = "AVAILTUNES" > +get_tune_parameters[vardepsexclude] = "AVAILTUNES TUNE_CCARGS" > > DEBIANNAME_${MLPREFIX}libgcc = "libgcc1" > > diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc > index 3cb6ec8..31e3cc4 100644 > --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc > +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc > @@ -61,7 +61,7 @@ EXTRA_OECONF_append_libc-uclibc = " --enable-__cxa_atexit" > EXTRA_OECONF_append_mips64 = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64" > EXTRA_OECONF_append_mips64el = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64" > > -EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}" > +EXTRA_OECONF_FPU ??= "" > CPPFLAGS = "" > > # powerpc needs this to comply with the ABI > diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc > index 45a1637..de906d6 100644 > --- a/meta/recipes-devtools/gcc/gcc-target.inc > +++ b/meta/recipes-devtools/gcc/gcc-target.inc > @@ -7,6 +7,8 @@ EXTRA_OECONF_PATHS = " \ > --with-native-system-header-dir=${STAGING_DIR_TARGET}${target_includedir} \ > --with-gxx-include-dir=${includedir}/c++/" > > +EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}" > + > PACKAGES = "\ > ${PN} ${PN}-plugins ${PN}-symlinks \ > g++ g++-symlinks \ > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc-common: Only apply fpu settings to target gcc 2014-10-27 19:54 ` Kristof Robot @ 2014-10-27 22:59 ` Richard Purdie 2014-10-28 10:30 ` Kristof Robot 0 siblings, 1 reply; 6+ messages in thread From: Richard Purdie @ 2014-10-27 22:59 UTC (permalink / raw) To: Kristof Robot; +Cc: openembedded-core On Mon, 2014-10-27 at 20:54 +0100, Kristof Robot wrote: > Richard, all, > > After bisecting, I found that, since this patch, my toolchain is being > built with soft floating point support, while it should be built with > hard floating point support: > > (1) Compiling parent commit 74d8866814aec520822518cc4cb8a942f7069bf7 > [1] gives hard floating point support (good): > $./build.good74d8/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc > -dM -E - < /dev/null | grep -i SOFTFP > $ > > (2) Compiling with this patch (commit > ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf [2]) gives soft floating > point support (bad): > $ ./build.badce1f/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc > -dM -E - < /dev/null | grep -i SOFTFP > #define __SOFTFP__ 1 > $ > > I am using DEFAULTTUNE = "cortexa7hf-neon-vfpv4", resulting in > following build configuration parameters: > TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard vfpv4 cortexa7" > TARGET_FPU = "vfp-vfpv4-neon" When building in OE, we always pass in the correct flags to gcc to ensure the correct thing gets built. The option you're changing with the revert just changed the default used by gcc if no option is specified on the commandline, so the change of the above test isn't a surprise. What is the real world problem you're seeing due to this? Is it caused by some compiler flags not being passed in somewhere? Note that some changes in master-next start to make the problem much more obvious by poisoning the default sysroot option to the compiler. When such options get lost, the failures should then be much clearer. Cheers, Richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc-common: Only apply fpu settings to target gcc 2014-10-27 22:59 ` Richard Purdie @ 2014-10-28 10:30 ` Kristof Robot 2014-10-28 11:31 ` Richard Purdie [not found] ` <CAFgGSN7R=pnPNrakJLZqG4S7ENiHx5qiaRSudb--LR-CTpELXw@mail.gmail.com> 0 siblings, 2 replies; 6+ messages in thread From: Kristof Robot @ 2014-10-28 10:30 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Mon, Oct 27, 2014 at 11:59 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Mon, 2014-10-27 at 20:54 +0100, Kristof Robot wrote: >> Richard, all, >> >> After bisecting, I found that, since this patch, my toolchain is being >> built with soft floating point support, while it should be built with >> hard floating point support: >> [snip] >> I am using DEFAULTTUNE = "cortexa7hf-neon-vfpv4", resulting in >> following build configuration parameters: >> TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard vfpv4 cortexa7" >> TARGET_FPU = "vfp-vfpv4-neon" > > When building in OE, we always pass in the correct flags to gcc to > ensure the correct thing gets built. The option you're changing with the > revert just changed the default used by gcc if no option is specified on > the commandline, so the change of the above test isn't a surprise. > > What is the real world problem you're seeing due to this? Is it caused > by some compiler flags not being passed in somewhere? The real world problem is a compilation of the meta-ros libfreenect library [1] for a Cubieboard2 [2] - this build fails because the compiler fails to find <gnu/stubs-hard.h> (only gnu/stubs-soft.h is available). In other words, somehow libfreenect (correctly) expects hard floating point, but then runs into troubles as the toolchain is (incorrectly) compiled using soft floating point. See also [3], which describes a similar problem, and [4], which seems to provide relevant info. More generally, I would actually assume that everything is being built hard floating point, as a result of the provided DEFAULTTUNE = "cortexa7hf-neon-vfpv4". Isn't this the correct way to force hard floating point? Thanks! Kristof [1] https://github.com/bmwcarit/meta-ros/blob/master/recipes-extended/libfreenect/libfreenect_0.2.1.bb [2] http://cubieboard.org/2013/06/19/cubieboard2-is-here/ [3] https://gcc.gnu.org/ml/gcc-help/2013-02/msg00141.html [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gcc-common: Only apply fpu settings to target gcc 2014-10-28 10:30 ` Kristof Robot @ 2014-10-28 11:31 ` Richard Purdie [not found] ` <CAFgGSN7R=pnPNrakJLZqG4S7ENiHx5qiaRSudb--LR-CTpELXw@mail.gmail.com> 1 sibling, 0 replies; 6+ messages in thread From: Richard Purdie @ 2014-10-28 11:31 UTC (permalink / raw) To: Kristof Robot; +Cc: openembedded-core On Tue, 2014-10-28 at 11:30 +0100, Kristof Robot wrote: > On Mon, Oct 27, 2014 at 11:59 PM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Mon, 2014-10-27 at 20:54 +0100, Kristof Robot wrote: > >> Richard, all, > >> > >> After bisecting, I found that, since this patch, my toolchain is being > >> built with soft floating point support, while it should be built with > >> hard floating point support: > >> > [snip] > >> I am using DEFAULTTUNE = "cortexa7hf-neon-vfpv4", resulting in > >> following build configuration parameters: > >> TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard vfpv4 cortexa7" > >> TARGET_FPU = "vfp-vfpv4-neon" > > > > When building in OE, we always pass in the correct flags to gcc to > > ensure the correct thing gets built. The option you're changing with the > > revert just changed the default used by gcc if no option is specified on > > the commandline, so the change of the above test isn't a surprise. > > > > What is the real world problem you're seeing due to this? Is it caused > > by some compiler flags not being passed in somewhere? > > The real world problem is a compilation of the meta-ros libfreenect > library [1] for a Cubieboard2 [2] - this build fails because the > compiler fails to find <gnu/stubs-hard.h> (only gnu/stubs-soft.h is > available). > In other words, somehow libfreenect (correctly) expects hard floating > point, but then runs into troubles as the toolchain is (incorrectly) > compiled using soft floating point. > See also [3], which describes a similar problem, and [4], which seems > to provide relevant info. > > More generally, I would actually assume that everything is being built > hard floating point, as a result of the provided DEFAULTTUNE = > "cortexa7hf-neon-vfpv4". > > Isn't this the correct way to force hard floating point? There is something wrong somewhere by the sounds of it but I'm not 100% sure where. With that tune, bitbake -e | grep CC= should show that CC is something along the lines of: CC="arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a7 --sysroot=X" the key part being -mfloat-abi=hard. When (e)glibc is built, which should be built specifically for this configuration, it should see that setting in the various flags and should generate headers like: ./image/usr/include/gnu/stubs-hard.h ./image/usr/include/gnu/stubs.h i.e. it should build a C library that matches this configuration and has the right headers. When libfreenect is built, the right headers should then be available. So, I'd suggest checking that the compiler flags in CC are what you'd expect and then that the C library is built with the right format headers. Something, somewhere isn't honouring the flags correctly as far as I can tell but I don't know what. Also, I'd be aware of the fact that we build one cross compiler (gcc-cross) for arm which is meant to work for all arm targets. If you build a softfloat something, then a hardfloat machine, it may be that something bad is creeping into the build process and a straight revert may not reproduce the bug you're seeing. Cheers, Richard ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAFgGSN7R=pnPNrakJLZqG4S7ENiHx5qiaRSudb--LR-CTpELXw@mail.gmail.com>]
[parent not found: <CAFgGSN76NRcBXG6Z=72aek3GVX=e7VqVDQ4FhdxoJLPg1af2ig@mail.gmail.com>]
[parent not found: <1414534100.7967.173.camel@ted>]
[parent not found: <CAFgGSN5T9UDFuzCqU+vsOSVy+uiwhxUf-ApGAQ80QAdSBoUHdQ@mail.gmail.com>]
[parent not found: <1414572117.7967.179.camel@ted>]
* Re: [PATCH] gcc-common: Only apply fpu settings to target gcc [not found] ` <1414572117.7967.179.camel@ted> @ 2014-10-29 9:24 ` Kristof Robot 0 siblings, 0 replies; 6+ messages in thread From: Kristof Robot @ 2014-10-29 9:24 UTC (permalink / raw) To: Richard Purdie, openembedded-core [re-adding the mailinglist] On Wed, Oct 29, 2014 at 9:41 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Wed, 2014-10-29 at 07:47 +0100, Kristof Robot wrote: >> On Tue, Oct 28, 2014 at 11:08 PM, Richard Purdie >> <richard.purdie@linuxfoundation.org> wrote: >> > On Tue, 2014-10-28 at 19:11 +0100, Kristof Robot wrote: >> >> On Tue, Oct 28, 2014 at 7:10 PM, Kristof Robot <krirobo@gmail.com> wrote: >> >> > On Tue, Oct 28, 2014 at 11:30 AM, Kristof Robot <krirobo@gmail.com> wrote: >> >> >> On Mon, Oct 27, 2014 at 11:59 PM, Richard Purdie >> >> >> <richard.purdie@linuxfoundation.org> wrote: >> >> >>> On Mon, 2014-10-27 at 20:54 +0100, Kristof Robot wrote: >> >> >> The real world problem is a compilation of the meta-ros libfreenect >> >> >> library [1] for a Cubieboard2 [2] - this build fails because the >> >> >> compiler fails to find <gnu/stubs-hard.h> (only gnu/stubs-soft.h is >> >> >> available). >> >> >> >> This is incorrect. The build fails because the compiler fails to find >> >> <gnu/stubs-soft.h> (only gnu/stubs-hard.h is available): >> >> >> >> /build/tmp-glibc/sysroots/cubieboard2/usr/include/gnu/stubs.h:7:29: >> >> fatal error: gnu/stubs-soft.h: No such file or directory >> > >> > In that case, I believe this is cause the -mfloat=hard option to gcc is >> > not being passed in. That option should be set in CC= as exposed by >> > bitbake -e and therefore if I have to guess, the software in question is >> > "losing" the flag somewhere. >> >> Are you referring to the libfreenect software? >> >> Note that the problem is already present in the toolchain - while >> (e)glibc seems to be built correctly with hard floating point (as can >> be seen from the fact that gnu/stubs-hard.h is available), >> arm-oe-linux-gnueabi-gcc is NOT built with hard floating point, but >> with soft floating point, as indicated in my first email: >> >> (1) Compiling parent commit 74d8866814aec520822518cc4cb8a942f7069bf7 >> gives hard floating point support (good): >> $./build.good74d8/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc >> -dM -E - < /dev/null | grep -i SOFTFP >> $ >> >> (2) Compiling with this patch (commit >> ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf) gives soft floating point >> support (bad): >> $ ./build.badce1f/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc >> -dM -E - < /dev/null | grep -i SOFTFP >> #define __SOFTFP__ 1 >> $ > > If you pass the -mfloat=hard option to the tests above, you will find > that all of a sudden gcc behaves like a hardfloat system. All the patch > you're changing does is change the default that gcc has, it can support > both, depending on which flags it is passed. Aha, it is changing the *default* of gcc - now I got it - that makes sense. So the issue is not with gcc (or the toolchain in general). >> This can also be seen based on the presence (or absence of) __ARM_PCS_VP >> >> (1) commit 74d8866814aec520822518cc4cb8a9 (good) >> arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i ARM_PCS >> #define __ARM_PCS_VFP 1 >> >> (2) commit ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf (bad) >> arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i ARM_PCS >> #define __ARM_PCS 1 >> >> Or is this expected? > > Expected. > > I still believe there is a problem in libfreenect with it not passing > the options to the compiler that it should. Yups, you are right. After I understood that this patch was just changing the default gcc options, and that the issue was not with the toolchain, I had a better look at the libfreenect software, and it happens to have already tackled this exact issue ("Stop clobbering CFLAGS" [1]) in a later version. Thanks a lot for the help, and sorry for the noise! Kristof [1] https://github.com/OpenKinect/libfreenect/commit/0cbb86ec982d3e79ad5efa9d1b2b16724ae89bc5 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-29 9:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-01 15:40 [PATCH] gcc-common: Only apply fpu settings to target gcc Richard Purdie
2014-10-27 19:54 ` Kristof Robot
2014-10-27 22:59 ` Richard Purdie
2014-10-28 10:30 ` Kristof Robot
2014-10-28 11:31 ` Richard Purdie
[not found] ` <CAFgGSN7R=pnPNrakJLZqG4S7ENiHx5qiaRSudb--LR-CTpELXw@mail.gmail.com>
[not found] ` <CAFgGSN76NRcBXG6Z=72aek3GVX=e7VqVDQ4FhdxoJLPg1af2ig@mail.gmail.com>
[not found] ` <1414534100.7967.173.camel@ted>
[not found] ` <CAFgGSN5T9UDFuzCqU+vsOSVy+uiwhxUf-ApGAQ80QAdSBoUHdQ@mail.gmail.com>
[not found] ` <1414572117.7967.179.camel@ted>
2014-10-29 9:24 ` Kristof Robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox