| Message ID | 20180220215954.4092811-4-arnd@arndb.de |
|---|---|
| State | New |
| Headers | show |
| Series | ARM: hacks for link-time optimization | expand |
On Tue, 20 Feb 2018, Arnd Bergmann wrote: > We need some way to pass -mbig-endian to the linker during the > LTO link stage, otherwise we get a waning like > > arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian > > for each file we link in. > > There is probably a better method of passing that flag, I'm just > adding it to a different hack that I added earlier for x86 LTO > here. Didn't the patch below fix it for you already? ----- >8 Date: Fri, 1 Sep 2017 18:37:52 -0400 Subject: [PATCH] scripts/gcc-ld: LTO on ARM needs arch specific gcc flags Otherwise the final link where code generation happens produces code for the wrong ISA when the default CPU configured into gcc is not the one we need. Also display the actual command when invoked with "make V=1". Signed-off-by: Nicolas Pitre <nico@linaro.org> diff --git a/scripts/gcc-ld b/scripts/gcc-ld index d95dd0be38..fa53be2a34 100755 --- a/scripts/gcc-ld +++ b/scripts/gcc-ld @@ -27,4 +27,10 @@ while [ "$1" != "" ] ; do shift done -exec $CC $ARGS +case "${KBUILD_VERBOSE}" in +*1*) + set -x + ;; +esac + +exec $CC $KBUILD_CFLAGS $ARGS
On 20 February 2018 at 21:59, Arnd Bergmann <arnd@arndb.de> wrote: > We need some way to pass -mbig-endian to the linker during the > LTO link stage, otherwise we get a waning like > > arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian > > for each file we link in. > > There is probably a better method of passing that flag, I'm just > adding it to a different hack that I added earlier for x86 LTO > here. > In general, LTO requires that *all* C flags are passed to the linker. Given that linking now involves code generation, any C flag that affects code generation must be visible to the linker as well, which includes all the tweaks and overrides that we add per-file or per-directory. It is not clear to me how much of this is carried in the intermediate representation as metadata, but we should probably err on the side of caution here, and update the Kbuild routines to pass the complete value of KBUILD_CFLAGS (or whatever it is called) to ld as well. > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/arm/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 33b7eb4502aa..f39c2e2d55c0 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -49,11 +49,13 @@ endif > > ifeq ($(CONFIG_CPU_BIG_ENDIAN),y) > KBUILD_CPPFLAGS += -mbig-endian > +KBUILD_BIARCHFLAGS += -mbig-endian > CHECKFLAGS += -D__ARMEB__ > AS += -EB > LD += -EB > else > KBUILD_CPPFLAGS += -mlittle-endian > +KBUILD_BIARCHFLAGS += -mlittle-endian > CHECKFLAGS += -D__ARMEL__ > AS += -EL > LD += -EL > -- > 2.9.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Feb 21, 2018 at 4:15 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Tue, 20 Feb 2018, Arnd Bergmann wrote: > >> We need some way to pass -mbig-endian to the linker during the >> LTO link stage, otherwise we get a waning like >> >> arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian >> >> for each file we link in. >> >> There is probably a better method of passing that flag, I'm just >> adding it to a different hack that I added earlier for x86 LTO >> here. > > Didn't the patch below fix it for you already? I think the problem here is that -mbig-endian is part of KBUILD_CPPFLAGS, not KBUILD_CFLAGS. We add the latter to the gcc-ld command line, but not the former. Arnd
On Wed, Feb 21, 2018 at 9:37 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 20 February 2018 at 21:59, Arnd Bergmann <arnd@arndb.de> wrote: >> We need some way to pass -mbig-endian to the linker during the >> LTO link stage, otherwise we get a waning like >> >> arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian >> >> for each file we link in. >> >> There is probably a better method of passing that flag, I'm just >> adding it to a different hack that I added earlier for x86 LTO >> here. >> > > In general, LTO requires that *all* C flags are passed to the linker. > Given that linking now involves code generation, any C flag that > affects code generation must be visible to the linker as well, which > includes all the tweaks and overrides that we add per-file or > per-directory. It is not clear to me how much of this is carried in > the intermediate representation as metadata, but we should probably > err on the side of caution here, and update the Kbuild routines to > pass the complete value of KBUILD_CFLAGS (or whatever it is called) to > ld as well. It looks like we're just missing KBUILD_CPPFLAGS. However, I wonder for the more general case what happens to files that require non-standard CFLAGS. In some cases we turn off some optimization step for a file, we might remove '-pg', or build for a particular target architecture. Do we have to turn off -flto for any file that requires this for correct behavior? Arnd
On 21 February 2018 at 09:48, Arnd Bergmann <arnd@arndb.de> wrote: > On Wed, Feb 21, 2018 at 9:37 AM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: >> On 20 February 2018 at 21:59, Arnd Bergmann <arnd@arndb.de> wrote: >>> We need some way to pass -mbig-endian to the linker during the >>> LTO link stage, otherwise we get a waning like >>> >>> arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian >>> >>> for each file we link in. >>> >>> There is probably a better method of passing that flag, I'm just >>> adding it to a different hack that I added earlier for x86 LTO >>> here. >>> >> >> In general, LTO requires that *all* C flags are passed to the linker. >> Given that linking now involves code generation, any C flag that >> affects code generation must be visible to the linker as well, which >> includes all the tweaks and overrides that we add per-file or >> per-directory. It is not clear to me how much of this is carried in >> the intermediate representation as metadata, but we should probably >> err on the side of caution here, and update the Kbuild routines to >> pass the complete value of KBUILD_CFLAGS (or whatever it is called) to >> ld as well. > > It looks like we're just missing KBUILD_CPPFLAGS. > > However, I wonder for the more general case what happens to files > that require non-standard CFLAGS. That was kind of my point, yes. > In some cases we turn off > some optimization step for a file, we might remove '-pg', or build for > a particular target architecture. Do we have to turn off -flto for any file > that requires this for correct behavior? > Excellent question. I think the problem is that the file boundary is becoming blurred with LTO, and so any option that is absolutely required to build a single file correctly may need to be applied to vmlinux as a whole. Whether that is the case for any particular option depends on which compiler pass(es) is (are) affected by the option, i.e., whether it is taken into account when creating the intermediate representation.
On Wed, Feb 21, 2018 at 11:09 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 21 February 2018 at 09:48, Arnd Bergmann <arnd@arndb.de> wrote: >> On Wed, Feb 21, 2018 at 9:37 AM, Ard Biesheuvel >> <ard.biesheuvel@linaro.org> wrote: >>> On 20 February 2018 at 21:59, Arnd Bergmann <arnd@arndb.de> wrote: > >> In some cases we turn off >> some optimization step for a file, we might remove '-pg', or build for >> a particular target architecture. Do we have to turn off -flto for any file >> that requires this for correct behavior? >> > > Excellent question. I think the problem is that the file boundary is > becoming blurred with LTO, and so any option that is absolutely > required to build a single file correctly may need to be applied to > vmlinux as a whole. Whether that is the case for any particular option > depends on which compiler pass(es) is (are) affected by the option, > i.e., whether it is taken into account when creating the intermediate > representation. Newer compilers are able to change both the optimization and warning flags per function using a #pragma or _Pragma() directive or function attributes. There has been some recent discussion about requiring a newer gcc version, so if we do that, we could perhaps replace all the existing CFLAGS overrides with those pragmas. Arnd
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 33b7eb4502aa..f39c2e2d55c0 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -49,11 +49,13 @@ endif ifeq ($(CONFIG_CPU_BIG_ENDIAN),y) KBUILD_CPPFLAGS += -mbig-endian +KBUILD_BIARCHFLAGS += -mbig-endian CHECKFLAGS += -D__ARMEB__ AS += -EB LD += -EB else KBUILD_CPPFLAGS += -mlittle-endian +KBUILD_BIARCHFLAGS += -mlittle-endian CHECKFLAGS += -D__ARMEL__ AS += -EL LD += -EL
We need some way to pass -mbig-endian to the linker during the LTO link stage, otherwise we get a waning like arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian for each file we link in. There is probably a better method of passing that flag, I'm just adding it to a different hack that I added earlier for x86 LTO here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- arch/arm/Makefile | 2 ++ 1 file changed, 2 insertions(+) -- 2.9.0