[U-Boot] [RFC] C2011 standard for building U-Boot
Hello Tom,
for the UEFI implementation of U-Boot it would make defining string constants much easier using the following C 2011 notation:
u16 *foo = u"My lovely string";
Do you see any reason forcing us not to use features of C 2011?
In /Makefile I found the following:
ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif
# # Xtensa linker script cannot be preprocessed with -ansi because of # preprocessor operations on strings that don't make C identifiers. # ifeq ($(CONFIG_XTENSA),) LDPPFLAGS += -ansi endif
# Create a file containing the configuration options the image was built with quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
The GCC documentation teaches: -ansi: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
When I am building for arm64 I find these options actually used:
aarch64-linux-gnu-gcc -Wp,-MD,common/.cli_hush.o.d -nostdinc -isystem /usr/lib/gcc-cross/aarch64-linux-gnu/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -fno-pic -mstrict-align -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe -march=armv8-a -D__LINUX_ARM_ARCH__=8 -I./arch/arm/mach-meson/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(cli_hush)" -D"KBUILD_MODNAME=KBUILD_STR(cli_hush)" -c -o common/cli_hush.o common/cli_hush.c
My impression is that:
We have variables in /Makefile that are not used for anything: LDPPFLAGS, cmd_cpp_cfg, cmd_cpp_lds.
All lines refering to these variables should be removed. Cf. https://lists.denx.de/pipermail/u-boot/2016-September/267177.html
We force C90 on cygwin to compile the host code but not for the actual U-Boot code. Probably a remnant from a distant past.
So nothing should stop us from using C2011 in U-Boot.
Would you agree?
Best regards
Heinrich
Thanks Heinrich
Just for everyone else's information, the background is that a UEFI implementation *really* wants utf16, and this suggestion avoids needing -fshort-wchar globally (or a lot of clumsiness in efi_loader)
BR, -R
On Thu, Aug 3, 2017 at 12:27 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Tom,
for the UEFI implementation of U-Boot it would make defining string constants much easier using the following C 2011 notation:
u16 *foo = u"My lovely string";
Do you see any reason forcing us not to use features of C 2011?
In /Makefile I found the following:
ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif
# # Xtensa linker script cannot be preprocessed with -ansi because of # preprocessor operations on strings that don't make C identifiers. # ifeq ($(CONFIG_XTENSA),) LDPPFLAGS += -ansi endif
# Create a file containing the configuration options the image was built with quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
The GCC documentation teaches: -ansi: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
When I am building for arm64 I find these options actually used:
aarch64-linux-gnu-gcc -Wp,-MD,common/.cli_hush.o.d -nostdinc -isystem /usr/lib/gcc-cross/aarch64-linux-gnu/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -fno-pic -mstrict-align -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe -march=armv8-a -D__LINUX_ARM_ARCH__=8 -I./arch/arm/mach-meson/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(cli_hush)" -D"KBUILD_MODNAME=KBUILD_STR(cli_hush)" -c -o common/cli_hush.o common/cli_hush.c
My impression is that:
We have variables in /Makefile that are not used for anything: LDPPFLAGS, cmd_cpp_cfg, cmd_cpp_lds.
All lines refering to these variables should be removed. Cf. https://lists.denx.de/pipermail/u-boot/2016-September/267177.html
We force C90 on cygwin to compile the host code but not for the actual U-Boot code. Probably a remnant from a distant past.
So nothing should stop us from using C2011 in U-Boot.
Would you agree?
Best regards
Heinrich
On Thu, Aug 03, 2017 at 06:27:02AM +0200, Heinrich Schuchardt wrote:
Hello Tom,
for the UEFI implementation of U-Boot it would make defining string constants much easier using the following C 2011 notation:
u16 *foo = u"My lovely string";
Do you see any reason forcing us not to use features of C 2011?
In /Makefile I found the following:
ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif
# # Xtensa linker script cannot be preprocessed with -ansi because of # preprocessor operations on strings that don't make C identifiers. # ifeq ($(CONFIG_XTENSA),) LDPPFLAGS += -ansi endif
# Create a file containing the configuration options the image was built with quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
The GCC documentation teaches: -ansi: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
When I am building for arm64 I find these options actually used:
aarch64-linux-gnu-gcc -Wp,-MD,common/.cli_hush.o.d -nostdinc -isystem /usr/lib/gcc-cross/aarch64-linux-gnu/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -fno-pic -mstrict-align -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe -march=armv8-a -D__LINUX_ARM_ARCH__=8 -I./arch/arm/mach-meson/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(cli_hush)" -D"KBUILD_MODNAME=KBUILD_STR(cli_hush)" -c -o common/cli_hush.o common/cli_hush.c
My impression is that:
We have variables in /Makefile that are not used for anything: LDPPFLAGS, cmd_cpp_cfg, cmd_cpp_lds.
All lines refering to these variables should be removed. Cf. https://lists.denx.de/pipermail/u-boot/2016-September/267177.html
OK. Drop 'em, throw travis-ci at it and see what, if anything, blows up.
We force C90 on cygwin to compile the host code but not for the actual U-Boot code. Probably a remnant from a distant past.
So nothing should stop us from using C2011 in U-Boot.
What's the minimum gcc (and llvm) version we need to use here? Thanks!
On Fri, Aug 4, 2017 at 9:20 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 06:27:02AM +0200, Heinrich Schuchardt wrote:
Hello Tom,
for the UEFI implementation of U-Boot it would make defining string constants much easier using the following C 2011 notation:
u16 *foo = u"My lovely string";
Do you see any reason forcing us not to use features of C 2011?
In /Makefile I found the following:
ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif
# # Xtensa linker script cannot be preprocessed with -ansi because of # preprocessor operations on strings that don't make C identifiers. # ifeq ($(CONFIG_XTENSA),) LDPPFLAGS += -ansi endif
# Create a file containing the configuration options the image was built with quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
The GCC documentation teaches: -ansi: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
When I am building for arm64 I find these options actually used:
aarch64-linux-gnu-gcc -Wp,-MD,common/.cli_hush.o.d -nostdinc -isystem /usr/lib/gcc-cross/aarch64-linux-gnu/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -fno-pic -mstrict-align -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe -march=armv8-a -D__LINUX_ARM_ARCH__=8 -I./arch/arm/mach-meson/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(cli_hush)" -D"KBUILD_MODNAME=KBUILD_STR(cli_hush)" -c -o common/cli_hush.o common/cli_hush.c
My impression is that:
We have variables in /Makefile that are not used for anything: LDPPFLAGS, cmd_cpp_cfg, cmd_cpp_lds.
All lines refering to these variables should be removed. Cf. https://lists.denx.de/pipermail/u-boot/2016-September/267177.html
OK. Drop 'em, throw travis-ci at it and see what, if anything, blows up.
We force C90 on cygwin to compile the host code but not for the actual U-Boot code. Probably a remnant from a distant past.
So nothing should stop us from using C2011 in U-Boot.
What's the minimum gcc (and llvm) version we need to use here? Thanks!
It looks like probably gcc 4.9[1].. maybe 4.7 or even v4.6[2] is complete enough for what we need.. that seems plenty old enough. I'm less familiar with clang but wikipedia says 3.1[2].
If some board/arch was stuck on something older, I guess we could make it a kconfig option that EFI_LOADER depends on.
[1] https://gcc.gnu.org/wiki/C11Status [2] https://en.wikipedia.org/wiki/C11_(C_standard_revision)
BR, -R
On 08/04/2017 03:53 PM, Rob Clark wrote:
On Fri, Aug 4, 2017 at 9:20 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Aug 03, 2017 at 06:27:02AM +0200, Heinrich Schuchardt wrote:
Hello Tom,
for the UEFI implementation of U-Boot it would make defining string constants much easier using the following C 2011 notation:
u16 *foo = u"My lovely string";
Do you see any reason forcing us not to use features of C 2011?
In /Makefile I found the following:
ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif
# # Xtensa linker script cannot be preprocessed with -ansi because of # preprocessor operations on strings that don't make C identifiers. # ifeq ($(CONFIG_XTENSA),) LDPPFLAGS += -ansi endif
# Create a file containing the configuration options the image was built with quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
The GCC documentation teaches: -ansi: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
When I am building for arm64 I find these options actually used:
aarch64-linux-gnu-gcc -Wp,-MD,common/.cli_hush.o.d -nostdinc -isystem /usr/lib/gcc-cross/aarch64-linux-gnu/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -fno-pic -mstrict-align -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe -march=armv8-a -D__LINUX_ARM_ARCH__=8 -I./arch/arm/mach-meson/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(cli_hush)" -D"KBUILD_MODNAME=KBUILD_STR(cli_hush)" -c -o common/cli_hush.o common/cli_hush.c
My impression is that:
We have variables in /Makefile that are not used for anything: LDPPFLAGS, cmd_cpp_cfg, cmd_cpp_lds.
All lines refering to these variables should be removed. Cf. https://lists.denx.de/pipermail/u-boot/2016-September/267177.html
OK. Drop 'em, throw travis-ci at it and see what, if anything, blows up.
We force C90 on cygwin to compile the host code but not for the actual U-Boot code. Probably a remnant from a distant past.
So nothing should stop us from using C2011 in U-Boot.
What's the minimum gcc (and llvm) version we need to use here? Thanks!
It looks like probably gcc 4.9[1].. maybe 4.7 or even v4.6[2] is complete enough for what we need.. that seems plenty old enough. I'm less familiar with clang but wikipedia says 3.1[2].
If some board/arch was stuck on something older, I guess we could make it a kconfig option that EFI_LOADER depends on.
[1] https://gcc.gnu.org/wiki/C11Status [2] https://en.wikipedia.org/wiki/C11_(C_standard_revision)
BR, -R
Since gcc 4.7 the option -std=c11 is available. Since gcc 6.1 the default is -std=gnu11 (C2011 + gnu extensions) Cygwin provides gcc 6.3.
Clang 2.9 has C11 suppport selected by -std=c11. Since Clang 3.6 switch to C11 by default.
If it is compatible with the code base I think the best would be to explicitly set -std=c11.
I will prepare a patch and test with Travis CI.
Best regards
Heinrich
participants (3)
-
Heinrich Schuchardt -
Rob Clark -
Tom Rini