[U-Boot] [RFC 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 ---
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index f30dd8e..994d957 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
---
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 Mon, Sep 10, 2018 at 06:53:45AM -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
On 10 September 2018 at 15:53, 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
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
participants (3)
-
Bin Meng -
Simon Glass -
Tom Rini