[PATCH] gcc-common: Only apply fpu settings to target gcc

[PATCH] gcc-common: Only apply fpu settings to target gcc

[Richard Purdie]

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 \

Re: [PATCH] gcc-common: Only apply fpu settings to target gcc

[Kristof Robot]

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

Re: [PATCH] gcc-common: Only apply fpu settings to target gcc

[Richard Purdie]

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

Re: [PATCH] gcc-common: Only apply fpu settings to target gcc

[Kristof Robot]

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

Re: [PATCH] gcc-common: Only apply fpu settings to target gcc

[Richard Purdie]

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

Re: [PATCH] gcc-common: Only apply fpu settings to target gcc

[Kristof Robot]

[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