-
Notifications
You must be signed in to change notification settings - Fork 8k
Description
Describe the bug
An inclusion of sys/param.h
for MIN()
and MAX()
in the file modules/hal/espressif/components/hal/esp32s2/include/hal/gpspi_flash_ll.h
pulls in sys/syslimits.h
, causing builds for espressif targets to fail in ways that do not fail on any other platform that uses newlib.
- What target platform are you using?
adafruit_feather_esp32s2@C/esp32s2
, but the issue exists for most other targets that use an espressif SoC / the espressif HAL - What have you tried to diagnose or workaround this issue? examined the log output, run some manual tests
- Is this a regression? If yes, have you been able to "git bisect" it to a specific commit? 5cbb2a4
Regression
- This is a regression.
Steps to reproduce
Steps to reproduce the behavior
west build -p auto -b adafruit_feather_esp32s2@C/esp32s2 tests/lib/cpp/cxx -T cpp.main.newlib
- See error
Relevant log output
[149/258] Building C object zephyr/CMakeFiles/zephyr.dirHOME/zephyrproject/modules/hal/espressif/zephyr/common/flash_init.c.obj
In file included from HOME/zephyrproject/zephyr/lib/libc/newlib/include/limits.h:12,
from HOME/zephyrproject/zephyr/include/zephyr/kernel_includes.h:22,
from HOME/zephyrproject/zephyr/include/zephyr/kernel.h:17,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/driver/include/esp_private/spi_common_internal.h:11,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/spi_flash/include/esp_flash_internal.h:11,
from HOME/zephyrproject/modules/hal/espressif/zephyr/common/flash_init.c:11:
HOME/zephyrproject/zephyr/include/zephyr/posix/posix_limits.h:83: warning: "ARG_MAX" redefined
83 | #define ARG_MAX _POSIX_ARG_MAX
|
In file included from ZEPHYR_SDK_INSTALL_DIR/xtensa-espressif_esp32s2_zephyr-elf/xtensa-espressif_esp32s2_zephyr-elf/sys-include/sys/param.h:9,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/hal/esp32s2/include/hal/gpspi_flash_ll.h:22,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/hal/esp32s2/include/hal/spi_flash_ll.h:17,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/hal/include/hal/spi_flash_hal.h:17,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/spi_flash/include/esp_private/spi_flash_os.h:18,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/bootloader_support/bootloader_flash/include/bootloader_flash.h:11,
from HOME/zephyrproject/modules/hal/espressif/zephyr/esp32s2/../../components/bootloader_support/bootloader_flash/include/bootloader_flash_priv.h:15,
from HOME/zephyrproject/modules/hal/espressif/zephyr/common/flash_init.c:10:
ZEPHYR_SDK_INSTALL_DIR/xtensa-espressif_esp32s2_zephyr-elf/xtensa-espressif_esp32s2_zephyr-elf/sys-include/sys/syslimits.h:40: note: this is the location of the previous definition
40 | #define ARG_MAX 65536 /* max bytes for an exec function */
|
HOME/zephyrproject/zephyr/include/zephyr/posix/posix_limits.h:93: warning: "OPEN_MAX" redefined
93 | #define OPEN_MAX CONFIG_POSIX_OPEN_MAX
|
ZEPHYR_SDK_INSTALL_DIR/xtensa-espressif_esp32s2_zephyr-elf/xtensa-espressif_esp32s2_zephyr-elf/sys-include/sys/syslimits.h:50: note: this is the location of the previous definition
50 | #define OPEN_MAX 64 /* max open files per process */
|
HOME/zephyrproject/zephyr/include/zephyr/posix/posix_limits.h:96: warning: "PATH_MAX" redefined
96 | #define PATH_MAX _POSIX_PATH_MAX
|
ZEPHYR_SDK_INSTALL_DIR/xtensa-espressif_esp32s2_zephyr-elf/xtensa-espressif_esp32s2_zephyr-elf/sys-include/sys/syslimits.h:52: note: this is the location of the previous definition
52 | #define PATH_MAX 1024 /* max bytes in pathname */
|
Impact
Showstopper – Prevents release or major functionality; system unusable.
Environment
- OS: any
- Toolchain: Zephyr SDK
- 16f4d6c
Additional Context
This isn't limited to the one named test. It was not caught in CI since we mainly build for qemu targets and native_sim on a per-pr basis. However, it was caught in weekly CI, as we run extended build tests for multiple platforms.
Probably the ideal scenario is to modify the espressif hal to not break builds in ways that are not reproducible with other newlib-based platforms. E.g. the issue is not even reproducible with qemu_xtensa/dc233c/mmu
.
A workaround for now should be fine.