[U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally
The -fstrict-aliasing option is implicitly enabled at levels -O2, -O3, -Os by GCC. This option allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For example, the practice of reading from a different union member than the one most recently written to (called "type-punning") is common. In this case, "type-punning" only works if the memory is accessed through the union type, but might not work by taking the address, casting the resulting pointer and dereferencing the result, which is an undefined behavior per the "strict aliasing rules".
GCC's -Wstrict-aliasing (included in -Wall) option does not catch all cases, but does attempt to catch the more common pitfalls. So there are cases that GCC does not report but the codes are violating the "strict aliasing rules".
Given lots of codes that may be written to rely on "type-punning", and Linux kernel disables it by -fno-strict-aliasing globally, since U-Boot currently does this on nds32/riscv/x86 builds only, extend this for all architecture builds.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org ---
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index 1891c3a..12f15ba 100644 --- a/Makefile +++ b/Makefile @@ -372,7 +372,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ -Wno-format-security \ -fno-builtin -ffreestanding $(CSTD_FLAG) -KBUILD_CFLAGS += -fshort-wchar +KBUILD_CFLAGS += -fshort-wchar -fno-strict-aliasing KBUILD_AFLAGS := -D__ASSEMBLY__
# Don't generate position independent code
Now that we already disable the "strict-aliasing" globally, remove the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Rick Chen rick@andestech.com
---
arch/nds32/config.mk | 2 +- arch/riscv/config.mk | 2 +- arch/x86/config.mk | 1 - 3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/nds32/config.mk b/arch/nds32/config.mk index cb3d8b3..c5520fd 100644 --- a/arch/nds32/config.mk +++ b/arch/nds32/config.mk @@ -15,7 +15,7 @@ endif CONFIG_STANDALONE_LOAD_ADDR = 0x300000 \ -T $(srctree)/examples/standalone/nds32.lds
-PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -mrelax +PLATFORM_RELFLAGS += -fno-common -mrelax PLATFORM_RELFLAGS += -gdwarf-2 PLATFORM_CPPFLAGS += -D__nds32__ -G0 -ffixed-10 -fpie
diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index 219e666..c0b3858 100644 --- a/arch/riscv/config.mk +++ b/arch/riscv/config.mk @@ -31,7 +31,7 @@ CONFIG_STANDALONE_LOAD_ADDR = 0x00000000 \ -T $(srctree)/examples/standalone/riscv.lds
PLATFORM_CPPFLAGS += -ffixed-gp -fpic -PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 -ffunction-sections +PLATFORM_RELFLAGS += -fno-common -gdwarf-2 -ffunction-sections LDFLAGS_u-boot += --gc-sections -static -pie
EFI_CRT0 := crt0_riscv_efi.o diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 5b04feb..cc94071 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -5,7 +5,6 @@
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))
On 16 September 2018 at 23:35, Bin Meng bmeng.cn@gmail.com wrote:
Now that we already disable the "strict-aliasing" globally, remove the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Rick Chen rick@andestech.com
arch/nds32/config.mk | 2 +- arch/riscv/config.mk | 2 +- arch/x86/config.mk | 1 - 3 files changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Sun, Sep 16, 2018 at 10:35:29PM -0700, Bin Meng wrote:
Now that we already disable the "strict-aliasing" globally, remove the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Rick Chen rick@andestech.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
Hi Tom,
On Mon, Sep 17, 2018 at 1:30 PM Bin Meng bmeng.cn@gmail.com wrote:
The -fstrict-aliasing option is implicitly enabled at levels -O2, -O3, -Os by GCC. This option allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For example, the practice of reading from a different union member than the one most recently written to (called "type-punning") is common. In this case, "type-punning" only works if the memory is accessed through the union type, but might not work by taking the address, casting the resulting pointer and dereferencing the result, which is an undefined behavior per the "strict aliasing rules".
GCC's -Wstrict-aliasing (included in -Wall) option does not catch all cases, but does attempt to catch the more common pitfalls. So there are cases that GCC does not report but the codes are violating the "strict aliasing rules".
Given lots of codes that may be written to rely on "type-punning", and Linux kernel disables it by -fno-strict-aliasing globally, since U-Boot currently does this on nds32/riscv/x86 builds only, extend this for all architecture builds.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
When will this series be applied? Another risc-v series has conflicts in [PATCH 2/2] and if this is applied in mainline, I can respin my risc-v series on top of this to save some time for Rick's handle it himself.
Regards, Bin
On Thu, Sep 20, 2018 at 11:37:36AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Sep 17, 2018 at 1:30 PM Bin Meng bmeng.cn@gmail.com wrote:
The -fstrict-aliasing option is implicitly enabled at levels -O2, -O3, -Os by GCC. This option allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For example, the practice of reading from a different union member than the one most recently written to (called "type-punning") is common. In this case, "type-punning" only works if the memory is accessed through the union type, but might not work by taking the address, casting the resulting pointer and dereferencing the result, which is an undefined behavior per the "strict aliasing rules".
GCC's -Wstrict-aliasing (included in -Wall) option does not catch all cases, but does attempt to catch the more common pitfalls. So there are cases that GCC does not report but the codes are violating the "strict aliasing rules".
Given lots of codes that may be written to rely on "type-punning", and Linux kernel disables it by -fno-strict-aliasing globally, since U-Boot currently does this on nds32/riscv/x86 builds only, extend this for all architecture builds.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
When will this series be applied? Another risc-v series has conflicts in [PATCH 2/2] and if this is applied in mainline, I can respin my risc-v series on top of this to save some time for Rick's handle it himself.
I will try and get to this soon, thanks for your patience.
On Sun, Sep 16, 2018 at 10:35:28PM -0700, Bin Meng wrote:
The -fstrict-aliasing option is implicitly enabled at levels -O2, -O3, -Os by GCC. This option allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For example, the practice of reading from a different union member than the one most recently written to (called "type-punning") is common. In this case, "type-punning" only works if the memory is accessed through the union type, but might not work by taking the address, casting the resulting pointer and dereferencing the result, which is an undefined behavior per the "strict aliasing rules".
GCC's -Wstrict-aliasing (included in -Wall) option does not catch all cases, but does attempt to catch the more common pitfalls. So there are cases that GCC does not report but the codes are violating the "strict aliasing rules".
Given lots of codes that may be written to rely on "type-punning", and Linux kernel disables it by -fno-strict-aliasing globally, since U-Boot currently does this on nds32/riscv/x86 builds only, extend this for all architecture builds.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (3)
-
Bin Meng -
Simon Glass -
Tom Rini