arm arm-none-eabi build configs.c error

[hongshui3000]

Describe the bug
log

Building C object zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj
FAILED: zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj 
C:\gnu_arm_embedded\bin\arm-none-eabi-gcc.exe -DBUILD_VERSION=zephyr-v2.7.0 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -IE:/work/zephyr/kernel/include -IE:/work/zephyr/arch/arm/include -IE:/work/zephyr/include -IE:/work/build/zephyr/include/generated -IE:/work/ZCAN-sdk/soc/arm/ocean -IE:/work/include -IE:/work/modules/hal/cmsis/CMSIS/Core/Include -isystem E:/work/zephyr/lib/libc/minimal/include -isystem c:/gnu_arm_embedded/bin/../lib/gcc/arm-none-eabi/10.3.1/include -isystem c:/gnu_arm_embedded/bin/../lib/gcc/arm-none-eabi/10.3.1/include-fixed -Os -imacros E:/work/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m3 -mthumb -mabi=aapcs -mfp16-format=ieee -imacros E:/work/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=E:/work/ZCAN-sdk/samples/hello_world=CMAKE_SOURCE_DIR -fmacro-prefix-map=E:/work/zephyr=ZEPHYR_BASE -fmacro-prefix-map=E:/work/=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj -MF zephyr\CMakeFiles\zephyr.dir\misc\generated\configs.c.obj.d -o zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj -c E:/work/build/zephyr/misc/generated/configs.c
C:\Users\xxx\AppData\Local\Temp\cczi8eHd.s: Assembler messages:
C:\Users\xxx\AppData\Local\Temp\cczi8eHd.s:91: Error: missing expression
C:\Users\xxx\AppData\Local\Temp\cczi8eHd.s:97: Error: missing expression

arm-none-eabi Version:10.3.1

It seems that CONFIG_FLASH_SIZE and CONFIG_FLASH_BASE_ADDRESS must be configured
Otherwise, the generated configuration file is very strange


If CONFIG_XIP=n
Then you must write the following configuration
CONFIG_FLASH_SIZE=0
CONFIG_FLASH_BASE_ADDRESS=0x0

[tejlmand]

It seems that CONFIG_FLASH_SIZE and CONFIG_FLASH_BASE_ADDRESS must be configured

When XIP=y on arm arch the default value will be the chosen flash node as can be seen:

zephyr/arch/Kconfig

Lines 187 to 193 in f882d43

	config FLASH_SIZE
	int "Flash Size in kB"
	default $(dt_chosen_reg_size_int,$(DT_CHOSEN_Z_FLASH),0,K) if (XIP && (ARM ||ARM64)) || !ARM
	help
	This option specifies the size of the flash in kB. It is normally set by
	the board's defconfig file and the user should generally avoid modifying
	it via the menu configuration.

But as it can be seen from the help text, the default value should come from the board defconfig.
@hongshui3000 which board are you building for ?

[hongshui3000]

It seems that CONFIG_FLASH_SIZE and CONFIG_FLASH_BASE_ADDRESS must be configured

When XIP=y on arm arch the default value will be the chosen flash node as can be seen:

zephyr/arch/Kconfig

Lines 187 to 193 in f882d43

	config FLASH_SIZE
	int "Flash Size in kB"
	default $(dt_chosen_reg_size_int,$(DT_CHOSEN_Z_FLASH),0,K) if (XIP && (ARM ||ARM64)) || !ARM
	help
	This option specifies the size of the flash in kB. It is normally set by
	the board's defconfig file and the user should generally avoid modifying
	it via the menu configuration.

But as it can be seen from the help text, the default value should come from the board defconfig. @hongshui3000 which board are you building for ?

@tejlmand
I discovered this issue when porting a soc. This should be a configuration dependency issue, but it really needs to be discovered at compile time. I think it might be better for people to find the issue earlier.

[tejlmand]

I discovered this issue when porting a soc.

Then #41393 is not a bug.
It is your responsibility to ensure that this gets set, either at the SoC / SoC series level, or at the board level you are implementing.

Per default, use the information from devicetree.

Examples:

zephyr/soc/arm/nxp_imx/rt/Kconfig.defconfig.series

Lines 114 to 116 in bd4ddec

	config FLASH_SIZE
	default $(dt_node_reg_size_int,/soc/flexram@40028000/itcm@0,0,K) if SOC_SERIES_IMX_RT11XX
	default $(dt_node_reg_size_int,/soc/flexram@400b0000/itcm@0,0,K) if SOC_SERIES_IMX_RT10XX

zephyr/soc/xtensa/esp32/Kconfig.soc

Lines 23 to 25 in bd4ddec

	config FLASH_SIZE
	int
	default $(dt_node_reg_size_int,/soc/flash-controller@3ff42000/flash@0,0)

[mlsvrts]

@tejlmand I agree this isn't a real bug, but the compiler messages are not very friendly to diagnose. You have to go digging through the generated configuration file to find the root of the issue. Also, the behavior is not very consistent across Kconfig types.

Consider these settings from MCUBOOT:

config BOOT_SERIAL_DETECT_PORT
	string "GPIO device to trigger serial recovery mode"
	default GPIO_0 if SOC_FAMILY_NRF
	help
	  Zephyr GPIO device that contains the pin used to trigger
	  serial recovery mode.

config BOOT_SERIAL_DETECT_PIN
	int "Pin to trigger serial recovery mode"
	default 6 if BOARD_NRF9160DK_NRF9160
	default 11 if BOARD_NRF52840DK_NRF52840
	default 13 if BOARD_NRF52DK_NRF52832 || BOARD_NRF52833DK_NRF52833
	default 23 if BOARD_NRF5340PDK_NRF5340_CPUAPP || BOARD_NRF5340PDK_NRF5340_CPUAPP_NS || \
		BOARD_NRF5340DK_NRF5340_CPUAPP || BOARD_NRF5340DK_NRF5340_CPUAPP_NS
	help
	  Pin on the serial detect port that triggers serial recovery mode.

Leaving both of them unset, and without a valid 'default', I get this generated configuration:

CONFIG_BOOT_SERIAL_DETECT_PORT=""
CONFIG_BOOT_SERIAL_DETECT_PIN=

Actually, this is not wrong, since there is no such thing as an empty number; we can't pick some sane global default for this value type. However, this ultimately results in malformed assembly code via an 'empty argument' in the macro:

GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_BOOT_SERIAL_DETECT_PIN, );

This produces a fairly obtuse 'missing expression' error that this post is about.

One simple solution would be to intentionally generate an invalid macro:

GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_BOOT_SERIAL_DETECT_PIN);

Which at least produces an error that points the user in the right direction:

/root/zephyrproject/zephyr/build/zephyr/misc/generated/configs.c: In function '_ConfigAbsSyms':
/root/zephyrproject/zephyr/build/zephyr/misc/generated/configs.c:27:55: error: macro "GEN_ABSOLUTE_SYM_KCONFIG" requires 2 arguments, but only 1 given
   27 | GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_BOOT_SERIAL_DETECT_PIN);
      |                                                       ^
In file included from /root/zephyrproject/zephyr/include/toolchain.h:50,
                 from /root/zephyrproject/zephyr/build/zephyr/misc/generated/configs.c:7:
/root/zephyrproject/zephyr/include/toolchain/gcc.h:444: note: macro "GEN_ABSOLUTE_SYM_KCONFIG" defined here
  444 | #define GEN_ABSOLUTE_SYM_KCONFIG(name, value)       \
      | 
/root/zephyrproject/zephyr/build/zephyr/misc/generated/configs.c:27:1: error: 'GEN_ABSOLUTE_SYM_KCONFIG' undeclared (first use in this function)
   27 | GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_BOOT_SERIAL_DETECT_PIN);
      | ^~~~~~~~~~~~~~~~~~~~~~~~
/root/zephyrproject/zephyr/build/zephyr/misc/generated/configs.c:27:1: note: each undeclared identifier is reported only once for each function it appears in

[tejlmand]

This is not a bug, more a question on how a new SoC must be implemented.