This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
This breaks compilation with Fedora gcc-8 tool chains:
CHK include/generated/compile.h
LD [M] arch/arm64/crypto/sha512-ce.o
aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory
make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1
make: *** [Makefile:1029: arch/arm64/crypto] Error 2
Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
Signed-off-by: Laura Abbott <[email protected]>
---
A bit rushed and I'm still debugging but I wanted to send this out
before anyone else gets hit since it is -rc4. Seeing this on both native
and cross compiles.
---
arch/arm64/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 7976d2d242fa..f476d52ad8d6 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
KBUILD_CPPFLAGS += -mbig-endian
CHECKFLAGS += -D__AARCH64EB__
AS += -EB
-LDFLAGS += -EB -maarch64elfb
+LDFLAGS += -EB -maarch64linuxb
UTS_MACHINE := aarch64_be
else
KBUILD_CPPFLAGS += -mlittle-endian
CHECKFLAGS += -D__AARCH64EL__
AS += -EL
-LDFLAGS += -EL -maarch64elf
+LDFLAGS += -EL -maarch64linux
UTS_MACHINE := aarch64
endif
--
2.17.1
On 07/09/2018 01:09 PM, Laura Abbott wrote:
> This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
>
> This breaks compilation with Fedora gcc-8 tool chains:
>
> CHK include/generated/compile.h
> LD [M] arch/arm64/crypto/sha512-ce.o
> aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory
> make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1
> make: *** [Makefile:1029: arch/arm64/crypto] Error 2
>
> Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> Signed-off-by: Laura Abbott <[email protected]>
> ---
> A bit rushed and I'm still debugging but I wanted to send this out
> before anyone else gets hit since it is -rc4. Seeing this on both native
> and cross compiles.
The answer appears to be that Fedora binutils does not package the assembly
scripts. The logic behind this is not immediately obvious but it's been
removed since 2004. Obviously this is a packaging issue on Fedora's side
but I'd still like to revert since it is a build breakage and fixing
this might require some coordination. I'll send a v2 with clarified
commit text if there's agreement.
Thanks,
Laura
> ---
> arch/arm64/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 7976d2d242fa..f476d52ad8d6 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -LDFLAGS += -EB -maarch64elfb
> +LDFLAGS += -EB -maarch64linuxb
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64elf
> +LDFLAGS += -EL -maarch64linux
> UTS_MACHINE := aarch64
> endif
>
>
On Mon, Jul 9, 2018 at 4:24 PM Laura Abbott <[email protected]> wrote:
>
> On 07/09/2018 01:09 PM, Laura Abbott wrote:
> > This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
> >
> > This breaks compilation with Fedora gcc-8 tool chains:
> >
> > CHK include/generated/compile.h
> > LD [M] arch/arm64/crypto/sha512-ce.o
> > aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory
> > make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1
> > make: *** [Makefile:1029: arch/arm64/crypto] Error 2
> >
> > Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> > Signed-off-by: Laura Abbott <[email protected]>
> > ---
> > A bit rushed and I'm still debugging but I wanted to send this out
> > before anyone else gets hit since it is -rc4. Seeing this on both native
> > and cross compiles.
>
> The answer appears to be that Fedora binutils does not package the assembly
> scripts. The logic behind this is not immediately obvious but it's been
> removed since 2004. Obviously this is a packaging issue on Fedora's side
> but I'd still like to revert since it is a build breakage and fixing
> this might require some coordination. I'll send a v2 with clarified
> commit text if there's agreement.
Tested-by: Kevin Hilman <[email protected]>
FWIW, the build is broken with debian packaged toolchain also. I
noticed it on stretch[1], and this patch gets things building again.
Kevin
[1]
$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/aarch64-linux-gnu/6/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
6.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-arm64-cross/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-arm64-cross
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-arm64-cross
--with-arch-directory=aarch64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj
--enable-multiarch --enable-fix-cortex-a53-843419
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=aarch64-linux-gnu
--program-prefix=aarch64-linux-gnu-
--includedir=/usr/aarch64-linux-gnu/include
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)
Thanks, Laura.
I'll take this as a fix, and add a comment to the Makefile to justify
why we need the linux target.
Will
On Mon, Jul 09, 2018 at 01:09:56PM -0700, Laura Abbott wrote:
> This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
>
> This breaks compilation with Fedora gcc-8 tool chains:
>
> CHK include/generated/compile.h
> LD [M] arch/arm64/crypto/sha512-ce.o
> aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory
> make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1
> make: *** [Makefile:1029: arch/arm64/crypto] Error 2
>
> Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> Signed-off-by: Laura Abbott <[email protected]>
> ---
> A bit rushed and I'm still debugging but I wanted to send this out
> before anyone else gets hit since it is -rc4. Seeing this on both native
> and cross compiles.
> ---
> arch/arm64/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 7976d2d242fa..f476d52ad8d6 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -LDFLAGS += -EB -maarch64elfb
> +LDFLAGS += -EB -maarch64linuxb
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64elf
> +LDFLAGS += -EL -maarch64linux
> UTS_MACHINE := aarch64
> endif
>
> --
> 2.17.1
>
Hi,
On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> Thanks, Laura.
>
> I'll take this as a fix, and add a comment to the Makefile to justify
> why we need the linux target.
So this comes down to either breaking fedora/debian toolchains (that
don't support elf emulation mode) or breaking bare-metal toolchains
(that don't support linux emulation mode).
Since Linux is a bare-metal project that does not technically require
the linux target (who said using "Linux" for all things is confusing?),
I think it should aim for the elf target in the long term.
But well, breaking Linux build in common distros isn't good either, so I
guess it makes sense to revert this while distros toolchains are being
fixed. Hopefully, it won't take too long.
What do you think?
Cheers,
Paul
> Will
>
> On Mon, Jul 09, 2018 at 01:09:56PM -0700, Laura Abbott wrote:
> > This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
> >
> > This breaks compilation with Fedora gcc-8 tool chains:
> >
> > CHK include/generated/compile.h
> > LD [M] arch/arm64/crypto/sha512-ce.o
> > aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory
> > make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1
> > make: *** [Makefile:1029: arch/arm64/crypto] Error 2
> >
> > Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> > Signed-off-by: Laura Abbott <[email protected]>
> > ---
> > A bit rushed and I'm still debugging but I wanted to send this out
> > before anyone else gets hit since it is -rc4. Seeing this on both native
> > and cross compiles.
> > ---
> > arch/arm64/Makefile | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 7976d2d242fa..f476d52ad8d6 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> > KBUILD_CPPFLAGS += -mbig-endian
> > CHECKFLAGS += -D__AARCH64EB__
> > AS += -EB
> > -LDFLAGS += -EB -maarch64elfb
> > +LDFLAGS += -EB -maarch64linuxb
> > UTS_MACHINE := aarch64_be
> > else
> > KBUILD_CPPFLAGS += -mlittle-endian
> > CHECKFLAGS += -D__AARCH64EL__
> > AS += -EL
> > -LDFLAGS += -EL -maarch64elf
> > +LDFLAGS += -EL -maarch64linux
> > UTS_MACHINE := aarch64
> > endif
> >
> > --
> > 2.17.1
> >
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
> On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> > Thanks, Laura.
> >
> > I'll take this as a fix, and add a comment to the Makefile to justify
> > why we need the linux target.
>
> So this comes down to either breaking fedora/debian toolchains (that
> don't support elf emulation mode) or breaking bare-metal toolchains
> (that don't support linux emulation mode).
>
> Since Linux is a bare-metal project that does not technically require
> the linux target (who said using "Linux" for all things is confusing?),
> I think it should aim for the elf target in the long term.
>
> But well, breaking Linux build in common distros isn't good either, so I
> guess it makes sense to revert this while distros toolchains are being
> fixed. Hopefully, it won't take too long.
>
> What do you think?
Yes, we need to revert the change since it's a regression otherwise. I think
the best course of action here would be to find a way that we can either
tell the linker that it doesn't need the missing linker scripts because
we're providing our own, or find a way to pass different LD flags depending
on whether or not we have a linux toolchain.
For now, I've pushed the revert to for-next/fixes.
Will
On Tue, Jul 10, 2018 at 10:36:16AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
> > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> > > Thanks, Laura.
> > >
> > > I'll take this as a fix, and add a comment to the Makefile to justify
> > > why we need the linux target.
> >
> > So this comes down to either breaking fedora/debian toolchains (that
> > don't support elf emulation mode) or breaking bare-metal toolchains
> > (that don't support linux emulation mode).
> >
> > Since Linux is a bare-metal project that does not technically require
> > the linux target (who said using "Linux" for all things is confusing?),
> > I think it should aim for the elf target in the long term.
> >
> > But well, breaking Linux build in common distros isn't good either, so I
> > guess it makes sense to revert this while distros toolchains are being
> > fixed. Hopefully, it won't take too long.
> >
> > What do you think?
>
> Yes, we need to revert the change since it's a regression otherwise. I think
> the best course of action here would be to find a way that we can either
> tell the linker that it doesn't need the missing linker scripts because
> we're providing our own, or find a way to pass different LD flags depending
> on whether or not we have a linux toolchain.
>
> For now, I've pushed the revert to for-next/fixes.
Hi Will,
This is regressed in mainline as well. But I think we can just use a (slightly
improved) ld-option here? I checked it for x86 regression since it uses the
one-argument version. Patch is here, can you pick that up instead and get it in
for 4.18-rc?
Thanks,
-Olof
From 0d73b2d1774d5edce20aac919ba356b61d098646 Mon Sep 17 00:00:00 2001
From: Olof Johansson <[email protected]>
Date: Fri, 13 Jul 2018 07:56:11 -0700
Subject: [PATCH] arm64: Fix build on some toolchains
Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in
particular. So, probe for whether it's available and use the previous
(linux) targets if it isn't.
Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
Signed-off-by: Olof Johansson <[email protected]>
---
arch/arm64/Makefile | 4 ++--
scripts/Kbuild.include | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 7976d2d242fa..c5ce97f69731 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
KBUILD_CPPFLAGS += -mbig-endian
CHECKFLAGS += -D__AARCH64EB__
AS += -EB
-LDFLAGS += -EB -maarch64elfb
+LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
UTS_MACHINE := aarch64_be
else
KBUILD_CPPFLAGS += -mlittle-endian
CHECKFLAGS += -D__AARCH64EL__
AS += -EL
-LDFLAGS += -EL -maarch64elf
+LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
UTS_MACHINE := aarch64
endif
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index c8156d61678c..1e13f502b42f 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -163,8 +163,8 @@ cc-ldoption = $(call try-run,\
$(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
# ld-option
-# Usage: LDFLAGS += $(call ld-option, -X)
-ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
+# Usage: LDFLAGS += $(call ld-option, -X, -Y)
+ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2),$(3))
# ar-option
# Usage: KBUILD_ARFLAGS := $(call ar-option,D)
--
2.11.0
On Fri, Jul 13, 2018 at 7:59 AM, Olof Johansson <[email protected]> wrote:
> On Tue, Jul 10, 2018 at 10:36:16AM +0100, Will Deacon wrote:
>> On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
>> > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
>> > > Thanks, Laura.
>> > >
>> > > I'll take this as a fix, and add a comment to the Makefile to justify
>> > > why we need the linux target.
>> >
>> > So this comes down to either breaking fedora/debian toolchains (that
>> > don't support elf emulation mode) or breaking bare-metal toolchains
>> > (that don't support linux emulation mode).
>> >
>> > Since Linux is a bare-metal project that does not technically require
>> > the linux target (who said using "Linux" for all things is confusing?),
>> > I think it should aim for the elf target in the long term.
>> >
>> > But well, breaking Linux build in common distros isn't good either, so I
>> > guess it makes sense to revert this while distros toolchains are being
>> > fixed. Hopefully, it won't take too long.
>> >
>> > What do you think?
>>
>> Yes, we need to revert the change since it's a regression otherwise. I think
>> the best course of action here would be to find a way that we can either
>> tell the linker that it doesn't need the missing linker scripts because
>> we're providing our own, or find a way to pass different LD flags depending
>> on whether or not we have a linux toolchain.
>>
>> For now, I've pushed the revert to for-next/fixes.
>
> Hi Will,
>
> This is regressed in mainline as well. But I think we can just use a (slightly
> improved) ld-option here? I checked it for x86 regression since it uses the
> one-argument version. Patch is here, can you pick that up instead and get it in
> for 4.18-rc?
>
> Thanks,
>
>
> -Olof
>
> From 0d73b2d1774d5edce20aac919ba356b61d098646 Mon Sep 17 00:00:00 2001
> From: Olof Johansson <[email protected]>
> Date: Fri, 13 Jul 2018 07:56:11 -0700
> Subject: [PATCH] arm64: Fix build on some toolchains
>
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in
> particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
> Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> Signed-off-by: Olof Johansson <[email protected]>
Of course, please add:
Reported-by: Laura Abbott <[email protected]>
or other suitable tag. Sloppy of me to miss.
-Olof
Hi Olof,
On Fri, Jul 13, 2018 at 07:59:10AM -0700, Olof Johansson wrote:
> On Tue, Jul 10, 2018 at 10:36:16AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
> > > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> > > > Thanks, Laura.
> > > >
> > > > I'll take this as a fix, and add a comment to the Makefile to justify
> > > > why we need the linux target.
> > >
> > > So this comes down to either breaking fedora/debian toolchains (that
> > > don't support elf emulation mode) or breaking bare-metal toolchains
> > > (that don't support linux emulation mode).
> > >
> > > Since Linux is a bare-metal project that does not technically require
> > > the linux target (who said using "Linux" for all things is confusing?),
> > > I think it should aim for the elf target in the long term.
> > >
> > > But well, breaking Linux build in common distros isn't good either, so I
> > > guess it makes sense to revert this while distros toolchains are being
> > > fixed. Hopefully, it won't take too long.
> > >
> > > What do you think?
> >
> > Yes, we need to revert the change since it's a regression otherwise. I think
> > the best course of action here would be to find a way that we can either
> > tell the linker that it doesn't need the missing linker scripts because
> > we're providing our own, or find a way to pass different LD flags depending
> > on whether or not we have a linux toolchain.
> >
> > For now, I've pushed the revert to for-next/fixes.
>
> Hi Will,
>
> This is regressed in mainline as well. But I think we can just use a (slightly
> improved) ld-option here? I checked it for x86 regression since it uses the
> one-argument version. Patch is here, can you pick that up instead and get it in
> for 4.18-rc?
I already sent the revert to Linus, but I can certainly queue the ld-option
for 4.19 if we pick up some more tested-bys. Could you send it out as its
own patch please?
Cheers,
Will
Hi,
On Fri, 2018-07-13 at 08:01 -0700, Olof Johansson wrote:
> On Fri, Jul 13, 2018 at 7:59 AM, Olof Johansson <[email protected]> wrote:
> > On Tue, Jul 10, 2018 at 10:36:16AM +0100, Will Deacon wrote:
> > > On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
> > > > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> > > > > Thanks, Laura.
> > > > >
> > > > > I'll take this as a fix, and add a comment to the Makefile to justify
> > > > > why we need the linux target.
> > > >
> > > > So this comes down to either breaking fedora/debian toolchains (that
> > > > don't support elf emulation mode) or breaking bare-metal toolchains
> > > > (that don't support linux emulation mode).
> > > >
> > > > Since Linux is a bare-metal project that does not technically require
> > > > the linux target (who said using "Linux" for all things is confusing?),
> > > > I think it should aim for the elf target in the long term.
> > > >
> > > > But well, breaking Linux build in common distros isn't good either, so I
> > > > guess it makes sense to revert this while distros toolchains are being
> > > > fixed. Hopefully, it won't take too long.
> > > >
> > > > What do you think?
> > >
> > > Yes, we need to revert the change since it's a regression otherwise. I think
> > > the best course of action here would be to find a way that we can either
> > > tell the linker that it doesn't need the missing linker scripts because
> > > we're providing our own, or find a way to pass different LD flags depending
> > > on whether or not we have a linux toolchain.
> > >
> > > For now, I've pushed the revert to for-next/fixes.
> >
> > Hi Will,
> >
> > This is regressed in mainline as well. But I think we can just use a (slightly
> > improved) ld-option here? I checked it for x86 regression since it uses the
> > one-argument version. Patch is here, can you pick that up instead and get it in
> > for 4.18-rc?
> >
> > Thanks,
> >
> >
> > -Olof
> >
> > From 0d73b2d1774d5edce20aac919ba356b61d098646 Mon Sep 17 00:00:00 2001
> > From: Olof Johansson <[email protected]>
> > Date: Fri, 13 Jul 2018 07:56:11 -0700
> > Subject: [PATCH] arm64: Fix build on some toolchains
> >
> > Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in
> > particular. So, probe for whether it's available and use the previous
> > (linux) targets if it isn't.
> >
> > Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
> > Signed-off-by: Olof Johansson <[email protected]>
>
> Of course, please add:
> Reported-by: Laura Abbott <[email protected]>
>
> or other suitable tag. Sloppy of me to miss.
Thanks for taking care of this patch!
I will definitely try it when I get the chance.
Cheers,
Paul
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
On Fri, Jul 13, 2018 at 8:07 AM, Will Deacon <[email protected]> wrote:
> Hi Olof,
>
> On Fri, Jul 13, 2018 at 07:59:10AM -0700, Olof Johansson wrote:
>> On Tue, Jul 10, 2018 at 10:36:16AM +0100, Will Deacon wrote:
>> > On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
>> > > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
>> > > > Thanks, Laura.
>> > > >
>> > > > I'll take this as a fix, and add a comment to the Makefile to justify
>> > > > why we need the linux target.
>> > >
>> > > So this comes down to either breaking fedora/debian toolchains (that
>> > > don't support elf emulation mode) or breaking bare-metal toolchains
>> > > (that don't support linux emulation mode).
>> > >
>> > > Since Linux is a bare-metal project that does not technically require
>> > > the linux target (who said using "Linux" for all things is confusing?),
>> > > I think it should aim for the elf target in the long term.
>> > >
>> > > But well, breaking Linux build in common distros isn't good either, so I
>> > > guess it makes sense to revert this while distros toolchains are being
>> > > fixed. Hopefully, it won't take too long.
>> > >
>> > > What do you think?
>> >
>> > Yes, we need to revert the change since it's a regression otherwise. I think
>> > the best course of action here would be to find a way that we can either
>> > tell the linker that it doesn't need the missing linker scripts because
>> > we're providing our own, or find a way to pass different LD flags depending
>> > on whether or not we have a linux toolchain.
>> >
>> > For now, I've pushed the revert to for-next/fixes.
>>
>> Hi Will,
>>
>> This is regressed in mainline as well. But I think we can just use a (slightly
>> improved) ld-option here? I checked it for x86 regression since it uses the
>> one-argument version. Patch is here, can you pick that up instead and get it in
>> for 4.18-rc?
>
> I already sent the revert to Linus, but I can certainly queue the ld-option
> for 4.19 if we pick up some more tested-bys. Could you send it out as its
> own patch please?
Definitely, separate email shortly.
-Olof
Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
in particular. So, probe for whether it's available and use the previous
(linux) targets if it isn't.
Reported-by: Laura Abbott <[email protected]>
Cc: Paul Kocialkowski <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
---
arch/arm64/Makefile | 9 +++++----
scripts/Kbuild.include | 4 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index e7101b19d590..efe61a2e4b5e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,15 +60,16 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
KBUILD_CPPFLAGS += -mbig-endian
CHECKFLAGS += -D__AARCH64EB__
AS += -EB
-# We must use the linux target here, since distributions don't tend to package
-# the ELF linker scripts with binutils, and this results in a build failure.
-LDFLAGS += -EB -maarch64linuxb
+# Prefer the baremetal ELF build target, but not all toolchains include
+# it so fall back to the standard linux version if needed.
+LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
UTS_MACHINE := aarch64_be
else
KBUILD_CPPFLAGS += -mlittle-endian
CHECKFLAGS += -D__AARCH64EL__
AS += -EL
-LDFLAGS += -EL -maarch64linux # See comment above
+# Same as above, prefer ELF but fall back to linux target if needed.
+LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
UTS_MACHINE := aarch64
endif
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index c8156d61678c..1e13f502b42f 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -163,8 +163,8 @@ cc-ldoption = $(call try-run,\
$(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
# ld-option
-# Usage: LDFLAGS += $(call ld-option, -X)
-ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
+# Usage: LDFLAGS += $(call ld-option, -X, -Y)
+ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2),$(3))
# ar-option
# Usage: KBUILD_ARFLAGS := $(call ar-option,D)
--
2.11.0
On 07/13/2018 08:30 AM, Olof Johansson wrote:
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
> in particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
For the Fedora toolchains:
Tested-by: Laura Abbott <[email protected]>
> Reported-by: Laura Abbott <[email protected]>
> Cc: Paul Kocialkowski <[email protected]>
> Signed-off-by: Olof Johansson <[email protected]>
> ---
> arch/arm64/Makefile | 9 +++++----
> scripts/Kbuild.include | 4 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index e7101b19d590..efe61a2e4b5e 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,15 +60,16 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -# We must use the linux target here, since distributions don't tend to package
> -# the ELF linker scripts with binutils, and this results in a build failure.
> -LDFLAGS += -EB -maarch64linuxb
> +# Prefer the baremetal ELF build target, but not all toolchains include
> +# it so fall back to the standard linux version if needed.
> +LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64linux # See comment above
> +# Same as above, prefer ELF but fall back to linux target if needed.
> +LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
> UTS_MACHINE := aarch64
> endif
>
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index c8156d61678c..1e13f502b42f 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -163,8 +163,8 @@ cc-ldoption = $(call try-run,\
> $(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
>
> # ld-option
> -# Usage: LDFLAGS += $(call ld-option, -X)
> -ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
> +# Usage: LDFLAGS += $(call ld-option, -X, -Y)
> +ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2),$(3))
>
> # ar-option
> # Usage: KBUILD_ARFLAGS := $(call ar-option,D)
>
On Fri, Jul 13, 2018 at 12:21 PM, Laura Abbott <[email protected]> wrote:
> On 07/13/2018 08:30 AM, Olof Johansson wrote:
>>
>> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
>> in particular. So, probe for whether it's available and use the previous
>> (linux) targets if it isn't.
>>
>
>
> For the Fedora toolchains:
>
> Tested-by: Laura Abbott <[email protected]>
Thanks!
-Olof
2018-07-14 0:30 GMT+09:00 Olof Johansson <[email protected]>:
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
> in particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
> Reported-by: Laura Abbott <[email protected]>
> Cc: Paul Kocialkowski <[email protected]>
> Signed-off-by: Olof Johansson <[email protected]>
> ---
> arch/arm64/Makefile | 9 +++++----
> scripts/Kbuild.include | 4 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index e7101b19d590..efe61a2e4b5e 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,15 +60,16 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -# We must use the linux target here, since distributions don't tend to package
> -# the ELF linker scripts with binutils, and this results in a build failure.
> -LDFLAGS += -EB -maarch64linuxb
> +# Prefer the baremetal ELF build target, but not all toolchains include
> +# it so fall back to the standard linux version if needed.
> +LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64linux # See comment above
> +# Same as above, prefer ELF but fall back to linux target if needed.
> +LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
> UTS_MACHINE := aarch64
> endif
>
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index c8156d61678c..1e13f502b42f 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -163,8 +163,8 @@ cc-ldoption = $(call try-run,\
> $(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
>
> # ld-option
> -# Usage: LDFLAGS += $(call ld-option, -X)
> -ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
> +# Usage: LDFLAGS += $(call ld-option, -X, -Y)
> +ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2),$(3))
>
> # ar-option
> # Usage: KBUILD_ARFLAGS := $(call ar-option,D)
I guess this patch will go through the arm64 tree.
I am fine with the change of scripts/Kbuild.include
Acked-by: Masahiro Yamada <[email protected]>
--
Best Regards
Masahiro Yamada
On 14 July 2018 at 00:30, Olof Johansson <[email protected]> wrote:
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
> in particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
> Reported-by: Laura Abbott <[email protected]>
> Cc: Paul Kocialkowski <[email protected]>
> Signed-off-by: Olof Johansson <[email protected]>
> ---
> arch/arm64/Makefile | 9 +++++----
> scripts/Kbuild.include | 4 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index e7101b19d590..efe61a2e4b5e 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,15 +60,16 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -# We must use the linux target here, since distributions don't tend to package
> -# the ELF linker scripts with binutils, and this results in a build failure.
> -LDFLAGS += -EB -maarch64linuxb
> +# Prefer the baremetal ELF build target, but not all toolchains include
> +# it so fall back to the standard linux version if needed.
> +LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64linux # See comment above
> +# Same as above, prefer ELF but fall back to linux target if needed.
> +LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
> UTS_MACHINE := aarch64
> endif
>
Did anyone check if just removing these options altogether would be an option?
The commit that introduced them does not even mention them, but only
mentions adding -mabi=lp64 to the cc/as flags:
commit 3d6a7b99e3fa29b92d6288487e057e0a596bd2b0
Author: Andrew Pinski <[email protected]>
Date: Mon Sep 18 11:20:20 2017 +0100
arm64: ensure the kernel is compiled for LP64
The kernel needs to be compiled as a LP64 binary for ARM64, even when
using a compiler that defaults to code-generation for the ILP32 ABI.
Consequently, we need to explicitly pass '-mabi=lp64' (supported on
gcc-4.9 and newer).
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index c8156d61678c..1e13f502b42f 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -163,8 +163,8 @@ cc-ldoption = $(call try-run,\
> $(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
>
> # ld-option
> -# Usage: LDFLAGS += $(call ld-option, -X)
> -ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
> +# Usage: LDFLAGS += $(call ld-option, -X, -Y)
> +ld-option = $(call try-run, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2),$(3))
>
> # ar-option
> # Usage: KBUILD_ARFLAGS := $(call ar-option,D)
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel