[U-Boot] [PATCH 1/2] x86: Use default stack boundary alignment
At present U-Boot x86 build is using -mpreferred-stack-boundary=2 which is 4 bytes stack boundary alignment. With 64-bit U-Boot, the minimal required stack boundary alignment is 16 bytes.
If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes). Switch to use the default one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/config.mk | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 74b87ce..043425e 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -10,8 +10,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000 PLATFORM_CPPFLAGS += -fno-strict-aliasing PLATFORM_CPPFLAGS += -fomit-frame-pointer PF_CPPFLAGS_X86 := $(call cc-option, -fno-toplevel-reorder, \ - $(call cc-option, -fno-unit-at-a-time)) \ - $(call cc-option, -mpreferred-stack-boundary=2) + $(call cc-option, -fno-unit-at-a-time))
PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_X86) PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
Attempting to use a 32-bit toolchain (eg: kernel.org 4.9 i386-linux-gcc) to compile 64-bit U-Boot (qemu-x86_64_defconfig) fails with the following errors:
arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register clobbered by 'ebx' in 'asm'
The issue is with 32-bit toolchain compiling sources for 64-bit. Using a 64-bit toolchain (eg: kernel.org 4.9 x86_64-linux-gcc) works out of the box. When compiling sources for 32-bit, '-m32' is passed to the toolchain (no matter it's 32-bit or 64-bit).
Now do the same thing, passing '-m64' to the toolchain for 64-bit sources build.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 043425e..8835dcf 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -26,7 +26,7 @@ endif ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64 endif
PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
Attempting to use a 32-bit toolchain (eg: kernel.org 4.9 i386-linux-gcc) to compile 64-bit U-Boot (qemu-x86_64_defconfig) fails with the following errors:
arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register clobbered by 'ebx' in 'asm'
The issue is with 32-bit toolchain compiling sources for 64-bit. Using a 64-bit toolchain (eg: kernel.org 4.9 x86_64-linux-gcc) works out of the box. When compiling sources for 32-bit, '-m32' is passed to the toolchain (no matter it's 32-bit or 64-bit).
Now do the same thing, passing '-m64' to the toolchain for 64-bit sources build.
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 043425e..8835dcf 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -26,7 +26,7 @@ endif ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64 endif
PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
2.9.2
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Andy,
On Sun, Jul 23, 2017 at 6:01 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
Attempting to use a 32-bit toolchain (eg: kernel.org 4.9 i386-linux-gcc) to compile 64-bit U-Boot (qemu-x86_64_defconfig) fails with the following errors:
arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register clobbered by 'ebx' in 'asm'
The issue is with 32-bit toolchain compiling sources for 64-bit. Using a 64-bit toolchain (eg: kernel.org 4.9 x86_64-linux-gcc) works out of the box. When compiling sources for 32-bit, '-m32' is passed to the toolchain (no matter it's 32-bit or 64-bit).
Now do the same thing, passing '-m64' to the toolchain for 64-bit sources build.
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Yes, multilib package is required for 64-bit toolchain to build 32-bit U-Boot. Maybe the confusion comes from what we call 32-bit/64-bit toolchains. Or maybe we should call it pre-configured toolchain for building 32-bit/64-bit codes? The issue is when using kernel.org i386-linux-gcc to build qemu-x86_64_defconfig (64-bit U-Boot), the issue is seen. It's because the i386-linux-gcc is pre-configured with '-m32' which is for building 32-bit codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Regards, Bin
On Sun, Jul 23, 2017 at 1:05 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:01 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Yes, multilib package is required for 64-bit toolchain to build 32-bit U-Boot. Maybe the confusion comes from what we call 32-bit/64-bit toolchains. Or maybe we should call it pre-configured toolchain for building 32-bit/64-bit codes? The issue is when using kernel.org i386-linux-gcc to build qemu-x86_64_defconfig (64-bit U-Boot), the issue is seen. It's because the i386-linux-gcc is pre-configured with '-m32' which is for building 32-bit codes.
My point is that subject (and maybe commit message) should be massaged a bit to avoid confusion.
Hi Andy,
On Sun, Jul 23, 2017 at 6:07 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:05 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:01 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Yes, multilib package is required for 64-bit toolchain to build 32-bit U-Boot. Maybe the confusion comes from what we call 32-bit/64-bit toolchains. Or maybe we should call it pre-configured toolchain for building 32-bit/64-bit codes? The issue is when using kernel.org i386-linux-gcc to build qemu-x86_64_defconfig (64-bit U-Boot), the issue is seen. It's because the i386-linux-gcc is pre-configured with '-m32' which is for building 32-bit codes.
My point is that subject (and maybe commit message) should be massaged a bit to avoid confusion.
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Regards, Bin
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:07 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:05 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:01 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Yes, multilib package is required for 64-bit toolchain to build 32-bit U-Boot. Maybe the confusion comes from what we call 32-bit/64-bit toolchains. Or maybe we should call it pre-configured toolchain for building 32-bit/64-bit codes? The issue is when using kernel.org i386-linux-gcc to build qemu-x86_64_defconfig (64-bit U-Boot), the issue is seen. It's because the i386-linux-gcc is pre-configured with '-m32' which is for building 32-bit codes.
My point is that subject (and maybe commit message) should be massaged a bit to avoid confusion.
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
Hi Andy,
On Sun, Jul 23, 2017 at 6:36 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:07 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:05 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:01 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 12:37 PM, Bin Meng bmeng.cn@gmail.com wrote:
The subject is a bit cofusing. As I read (and as I understand) we need to have 64-bit toolchain available (multilib package and so on). Basically what you do is "enforcing 64-bit toolchain to be used". Right?
Yes, multilib package is required for 64-bit toolchain to build 32-bit U-Boot. Maybe the confusion comes from what we call 32-bit/64-bit toolchains. Or maybe we should call it pre-configured toolchain for building 32-bit/64-bit codes? The issue is when using kernel.org i386-linux-gcc to build qemu-x86_64_defconfig (64-bit U-Boot), the issue is seen. It's because the i386-linux-gcc is pre-configured with '-m32' which is for building 32-bit codes.
My point is that subject (and maybe commit message) should be massaged a bit to avoid confusion.
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
-m64 will only be passed to compiler when building source files that are part of 64-bit U-Boot. For 32-bit U-Boot, it is still -m32.
Regards, Bin
On Sun, Jul 23, 2017 at 1:48 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:36 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:07 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
-m64 will only be passed to compiler when building source files that are part of 64-bit U-Boot. For 32-bit U-Boot, it is still -m32.
Yes, what I'm trying to understand is 1. U-Boot is compiled _either_ 64-bit, _or_ 32-bit binary -- correct? 2. If above is correct then -m64 _enforces_ to compile it as 64-bit -- correct?
Or I'm mistaken with the last and -m64 just adds a _preference_ to compile as 64-bit?
Hi Andy,
On Sun, Jul 23, 2017 at 8:51 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:48 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:36 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:07 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
-m64 will only be passed to compiler when building source files that are part of 64-bit U-Boot. For 32-bit U-Boot, it is still -m32.
Yes, what I'm trying to understand is
- U-Boot is compiled _either_ 64-bit, _or_ 32-bit binary -- correct?
64-bit U-Boot image is a combination of 32-bit U-Boot (SPL) plus 64-bit U-Boot (proper). For the U-Boot proper, it has be compiled with 64-bit and currently -m64 is missing, primary due to the toolchain we previously used has implicitly -m64 configured.
- If above is correct then -m64 _enforces_ to compile it as 64-bit -- correct?
Correct.
Or I'm mistaken with the last and -m64 just adds a _preference_ to compile as 64-bit?
Regards, Bin
On Sun, Jul 23, 2017 at 4:33 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 8:51 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:48 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:36 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
-m64 will only be passed to compiler when building source files that are part of 64-bit U-Boot. For 32-bit U-Boot, it is still -m32.
Yes, what I'm trying to understand is
- U-Boot is compiled _either_ 64-bit, _or_ 32-bit binary -- correct?
64-bit U-Boot image is a combination of 32-bit U-Boot (SPL) plus 64-bit U-Boot (proper). For the U-Boot proper, it has be compiled with 64-bit and currently -m64 is missing, primary due to the toolchain we previously used has implicitly -m64 configured.
Okay, thanks for patience and explanation.
Can you somehow (partially) inject this into initial subject + commit message?
Hi Andy,
On Sun, Jul 23, 2017 at 11:35 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 4:33 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 8:51 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:48 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Jul 23, 2017 at 6:36 PM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sun, Jul 23, 2017 at 1:26 PM, Bin Meng bmeng.cn@gmail.com wrote:
Sure. Reword it as "Allow toolchains that are pre-configured to build 32-bit codes to compile 64-bit U-Boot"?
Hmm... The flag you are adding does enforce or allow? So, if -m64 will still allow to compile 32-bit code, then it's allowing, otherwise it's enforcing. Or I miss something?
-m64 will only be passed to compiler when building source files that are part of 64-bit U-Boot. For 32-bit U-Boot, it is still -m32.
Yes, what I'm trying to understand is
- U-Boot is compiled _either_ 64-bit, _or_ 32-bit binary -- correct?
64-bit U-Boot image is a combination of 32-bit U-Boot (SPL) plus 64-bit U-Boot (proper). For the U-Boot proper, it has be compiled with 64-bit and currently -m64 is missing, primary due to the toolchain we previously used has implicitly -m64 configured.
Okay, thanks for patience and explanation.
Can you somehow (partially) inject this into initial subject + commit message?
Yes, will do in v2.
Regards, Bin
On 23 July 2017 at 03:37, Bin Meng bmeng.cn@gmail.com wrote:
At present U-Boot x86 build is using -mpreferred-stack-boundary=2 which is 4 bytes stack boundary alignment. With 64-bit U-Boot, the minimal required stack boundary alignment is 16 bytes.
If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes). Switch to use the default one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/config.mk | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
participants (3)
-
Andy Shevchenko -
Bin Meng -
Simon Glass