[U-Boot] [PATCH v1] Makefile: Don't generate position independent code
Since gcc-8 the --enabled-default-pie starts producing code which assembler can't translate in case of U-Boot. The build fails with
{standard input}: Assembler messages: {standard input}:21100: Error: junk at end of line, first unrecognized character is `@' {standard input}:21120: Error: junk at end of line, first unrecognized character is `@'
and so on.
This is usually the case for x86 platform because in many cases it uses host compiler from the Linux distributions, where PIE is enabled by default. Previously (gcc-7 and earlier) that was a potential issue due to absence of constructions like
.long end.5561@gotoff-start.5558@gotoff
which are a cause of above error messages in gcc-8.
Fix all these by disabling PIE on Makefile level.
Reported-by: Heinrich Schuchardt xypron.glpk@gmx.de Suggested-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com --- Makefile | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile index 884b7d943c..e2310f3552 100644 --- a/Makefile +++ b/Makefile @@ -375,6 +375,10 @@ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ KBUILD_CFLAGS += -fshort-wchar KBUILD_AFLAGS := -D__ASSEMBLY__
+# Don't generate position independent code +KBUILD_CFLAGS += $(call cc-option,-fno-PIE) +KBUILD_AFLAGS += $(call cc-option,-fno-PIE) + # Read UBOOTRELEASE from include/config/uboot.release (if it exists) UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null) UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Since gcc-8 the --enabled-default-pie starts producing code which assembler can't translate in case of U-Boot. The build fails with
{standard input}: Assembler messages: {standard input}:21100: Error: junk at end of line, first unrecognized character is `@' {standard input}:21120: Error: junk at end of line, first unrecognized character is `@'
and so on.
This is usually the case for x86 platform because in many cases it uses host compiler from the Linux distributions, where PIE is enabled by default. Previously (gcc-7 and earlier) that was a potential issue due to absence of constructions like
.long end.5561@gotoff-start.5558@gotoff
which are a cause of above error messages in gcc-8.
Fix all these by disabling PIE on Makefile level.
Reported-by: Heinrich Schuchardt xypron.glpk@gmx.de Suggested-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
Makefile | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile index 884b7d943c..e2310f3552 100644 --- a/Makefile +++ b/Makefile @@ -375,6 +375,10 @@ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ KBUILD_CFLAGS += -fshort-wchar KBUILD_AFLAGS := -D__ASSEMBLY__
+# Don't generate position independent code +KBUILD_CFLAGS += $(call cc-option,-fno-PIE) +KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
# Read UBOOTRELEASE from include/config/uboot.release (if it exists) UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null) UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
With the patch building with gcc-8.1 works on i386. But the interesting question is whether the EFI subsystem will be able to relocate the runtime code when the EFI service SetVirtualAddressMap() is called.
Did you boot Linux with the patch via bootefi and call any of the EFI runtime services from Linux?
As you are changing this for all architectures this needs to be tested on all (ARM, RISC-V, and x86) architectures supporting the EFI subsystem.
Best regards
Heinrich
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Fix all these by disabling PIE on Makefile level.
With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
But the interesting question is whether the EFI subsystem will be able to relocate the runtime code when the EFI service SetVirtualAddressMap() is called.
EFI code should have different CFLAGS I suppose.
Did you boot Linux with the patch via bootefi and call any of the EFI runtime services from Linux?
Nope, I have no platform with UEFI to test.
As you are changing this for all architectures this needs to be tested on all (ARM, RISC-V, and x86) architectures supporting the EFI subsystem.
Agree. Unfortunately I have almost none of them to play with. I leave this to others who able to confirm the patch works.
My understanding we need this anyway and if there are some problems, we need to fix them on individual basis.
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Fix all these by disabling PIE on Makefile level.
With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
But the interesting question is whether the EFI subsystem will be able to relocate the runtime code when the EFI service SetVirtualAddressMap() is called.
EFI code should have different CFLAGS I suppose.
This really depends on the architecture:
On RISC-V EFI specific flags are not defined.
On ARM CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections CFLAGS_EFI := -fpic -fshort-wchar
On x86 ifeq ($(IS_32BIT),y) CFLAGS_NON_EFI := -mregparm=3 endif CFLAGS_EFI := -fpic -fshort-wchar
Do you know how -fpic and -fno-PIE work together when both are passed to gcc?
CFLAGS_EFI is only used to compile standalone EFI executables like helloworld.efi not the EFI runtime. See lib/efi_loader/Makefile.
Best regards
Hienrich
Did you boot Linux with the patch via bootefi and call any of the EFI runtime services from Linux?
Nope, I have no platform with UEFI to test.
As you are changing this for all architectures this needs to be tested on all (ARM, RISC-V, and x86) architectures supporting the EFI subsystem.
Agree. Unfortunately I have almost none of them to play with. I leave this to others who able to confirm the patch works.
My understanding we need this anyway and if there are some problems, we need to fix them on individual basis.
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Fix all these by disabling PIE on Makefile level.
With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
But the interesting question is whether the EFI subsystem will be able to relocate the runtime code when the EFI service SetVirtualAddressMap() is called.
EFI code should have different CFLAGS I suppose.
This really depends on the architecture:
On RISC-V EFI specific flags are not defined.
On ARM CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata- sections CFLAGS_EFI := -fpic -fshort-wchar
On x86 ifeq ($(IS_32BIT),y) CFLAGS_NON_EFI := -mregparm=3 endif CFLAGS_EFI := -fpic -fshort-wchar
Do you know how -fpic and -fno-PIE work together when both are passed to gcc?
In all three cases where CONFIG_EFI is used there is no KBUILD_*FLAGS are in use. The special flags are for EFI apps as it supposed to be.
CFLAGS_EFI is only used to compile standalone EFI executables like helloworld.efi not the EFI runtime. See lib/efi_loader/Makefile.
Yes, I see no contradiction here.
On 08/06/2018 08:55 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Fix all these by disabling PIE on Makefile level.
With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
I can start qemu-x86_defconfig and run bootefi selftest with your patch.
odroid-c2_defconfig can boot both with either booti or bootefi with your patch.
Best regards
Heinrich
On Mon, Aug 6, 2018 at 10:40 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/06/2018 08:55 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
Fix all these by disabling PIE on Makefile level.
With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
I can start qemu-x86_defconfig and run bootefi selftest with your patch.
odroid-c2_defconfig can boot both with either booti or bootefi with your patch.
Thanks for testing!
On Mon, Aug 6, 2018 at 10:49 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Aug 6, 2018 at 10:40 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/06/2018 08:55 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 06:00 PM, Andy Shevchenko wrote: > Fix all these by disabling PIE on Makefile level. With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
I can start qemu-x86_defconfig and run bootefi selftest with your patch.
odroid-c2_defconfig can boot both with either booti or bootefi with your patch.
Thanks for testing!
Bin, can we get this applied? For now (*) it's a bit of burden to run make CC=gcc-7 each time I would like U-Boot to be built.
(*) It seems Debian (-like) distros, one of which we are using as an OS on build machines, switched to gcc-8 by default and this is a problem for native compilation.
Hi Andy,
On Thu, Aug 9, 2018 at 5:43 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Aug 6, 2018 at 10:49 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Aug 6, 2018 at 10:40 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/06/2018 08:55 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote: > On 08/06/2018 06:00 PM, Andy Shevchenko wrote: >> Fix all these by disabling PIE on Makefile level. > With the patch building with gcc-8.1 works on i386.
Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
I can start qemu-x86_defconfig and run bootefi selftest with your patch.
odroid-c2_defconfig can boot both with either booti or bootefi with your patch.
Thanks for testing!
Bin, can we get this applied? For now (*) it's a bit of burden to run make CC=gcc-7 each time I would like U-Boot to be built.
This was not assigned to me in patchwork. But yes, I can take this one via the x86 tree.
Heinrich,
I assume I can add your "Tested-by" tag since from patchwork I don't see this patch has any tags associated. Let me know if this is OK.
(*) It seems Debian (-like) distros, one of which we are using as an OS on build machines, switched to gcc-8 by default and this is a problem for native compilation.
--
Regards, Bin
On 08/09/2018 11:54 AM, Bin Meng wrote:
Hi Andy,
On Thu, Aug 9, 2018 at 5:43 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Aug 6, 2018 at 10:49 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Aug 6, 2018 at 10:40 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/06/2018 08:55 PM, Andy Shevchenko wrote:
On Mon, 2018-08-06 at 19:32 +0200, Heinrich Schuchardt wrote:
On 08/06/2018 07:11 PM, Andy Shevchenko wrote: > On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote: >> On 08/06/2018 06:00 PM, Andy Shevchenko wrote: >>> Fix all these by disabling PIE on Makefile level. >> With the patch building with gcc-8.1 works on i386. > > Does it mean you are actually run it and it works?
Can you confirm that binary you got is working for you?
I can start qemu-x86_defconfig and run bootefi selftest with your patch.
odroid-c2_defconfig can boot both with either booti or bootefi with your patch.
Thanks for testing!
Bin, can we get this applied? For now (*) it's a bit of burden to run make CC=gcc-7 each time I would like U-Boot to be built.
This was not assigned to me in patchwork. But yes, I can take this one via the x86 tree.
Heinrich,
I assume I can add your "Tested-by" tag since from patchwork I don't see this patch has any tags associated. Let me know if this is OK.
You can add the tag. But, please, observe that I did not test on the following architectures: RISC-V, ARM 32bit. I did not test loading of Linux on x86.
Best regards
Heinrich
(*) It seems Debian (-like) distros, one of which we are using as an OS on build machines, switched to gcc-8 by default and this is a problem for native compilation.
--
Regards, Bin
On Thu, 2018-08-09 at 14:25 +0200, Heinrich Schuchardt wrote:
I did not test loading of Linux on x86.
For the record I did test this.
On Thu, Aug 9, 2018 at 9:07 PM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Thu, 2018-08-09 at 14:25 +0200, Heinrich Schuchardt wrote:
I did not test loading of Linux on x86.
For the record I did test this.
Tested-by: Bin Meng bmeng.cn@gmail.com On QEMU x86 boards (except efi-x86_app_defconfig which is currently broken)
applied to u-boot-x86, thanks!
Hi,
On 10 August 2018 at 00:04, Bin Meng bmeng.cn@gmail.com wrote:
On Thu, Aug 9, 2018 at 9:07 PM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Thu, 2018-08-09 at 14:25 +0200, Heinrich Schuchardt wrote:
I did not test loading of Linux on x86.
For the record I did test this.
Tested-by: Bin Meng bmeng.cn@gmail.com On QEMU x86 boards (except efi-x86_app_defconfig which is currently broken)
applied to u-boot-x86, thanks!
This appears to break build sandbox on Ubuntu 18.04 at least (gcc-7.3).
Can we revert it, or do something else stop it from happening with sandbox?
At present all testing is broken for me.
Regards, Simon
On Sun, Sep 02, 2018 at 05:50:24PM -0600, Simon Glass wrote:
Hi,
On 10 August 2018 at 00:04, Bin Meng bmeng.cn@gmail.com wrote:
On Thu, Aug 9, 2018 at 9:07 PM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Thu, 2018-08-09 at 14:25 +0200, Heinrich Schuchardt wrote:
I did not test loading of Linux on x86.
For the record I did test this.
Tested-by: Bin Meng bmeng.cn@gmail.com On QEMU x86 boards (except efi-x86_app_defconfig which is currently broken)
applied to u-boot-x86, thanks!
This appears to break build sandbox on Ubuntu 18.04 at least (gcc-7.3).
Sandbox is not a real bootloader for sure :-)
Does the below cure?
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index 5e7077bfe7..4599839791 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -3,6 +3,7 @@
PLATFORM_CPPFLAGS += -D__SANDBOX__ -U_FORTIFY_SOURCE PLATFORM_CPPFLAGS += -DCONFIG_ARCH_MAP_SYSMEM +PLATFORM_CPPFLAGS += -fPIC PLATFORM_LIBS += -lrt
LDFLAGS_FINAL += --gc-sections
Can we revert it, or do something else stop it from happening with sandbox?
At present all testing is broken for me.
participants (5)
-
Andy Shevchenko -
Andy Shevchenko -
Bin Meng -
Heinrich Schuchardt -
Simon Glass