Toolchain built for 64bit wide time_t fails to build working hello-world-example (IDFGH-6318)
#7980
Comments
github-actions
bot
changed the title
time_t fails to build working hello-world-exampletime_t fails to build working hello-world-example (IDFGH-6318)
|
I tried "https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/get-started/linux-setup-scratch.html" rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) I (69) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (0) cpu_start: App cpu up. |
espressif-bot
added
Status: In Progress
|
Thank you for reporting @sven-hm @itadori-1. We found the issue and will soon fix it in The issue is caused by mismatch of Here is the patch which can be applied to Instead of applying the patch, you may also manually remove the following lines from components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld: |
|
Thanks @igrr for the fix! I can confirm that the suggested fix works with the example code. |
...and all their callers. With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8, sizeof(struct stat) is also increasing. A few newlib functions present in ROM allocate 'struct stat' on the stack and call _fstat_r on this structure. The implementation of fstat is provided in ESP-IDF. This implementation will often do memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting some fields of this structure. If IDF is built with sizeof(st) different from sizeof(st) which ROM was built with, this will lead to an out-of-bounds write and a stack corruption. This commit removes problematic ROM functions from the linker script. Here are the functions which allocate 'struct stat': * _isatty_r (in ROM) * __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and __srefill_r (in ROM) * _fseeko_r (not in ROM) * glob2 (not in ROM) * _gettemp (not in ROM) As a result, these functions are used from libc.a, and use correct size of 'stat' structure. Closes espressif#7980
espressif-bot
added
Resolution: Done
...and all their callers. With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8, sizeof(struct stat) is also increasing. A few newlib functions present in ROM allocate 'struct stat' on the stack and call _fstat_r on this structure. The implementation of fstat is provided in ESP-IDF. This implementation will often do memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting some fields of this structure. If IDF is built with sizeof(st) different from sizeof(st) which ROM was built with, this will lead to an out-of-bounds write and a stack corruption. This commit removes problematic ROM functions from the linker script. Here are the functions which allocate 'struct stat': * _isatty_r (in ROM) * __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and __srefill_r (in ROM) * _fseeko_r (not in ROM) * glob2 (not in ROM) * _gettemp (not in ROM) As a result, these functions are used from libc.a, and use correct size of 'stat' structure. Closes espressif#7980
|
@igrr in which release do you plan to include the fix? |
|
@sven-hm The fix is currently in I can also backport this to release/v4.4 and release/v4.3 branches, in this case the fix will appear in v4.4.1 and v4.3.3, respectively. |
|
Ok, nice! Thank you, @igrr ! |
...and all their callers. With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8, sizeof(struct stat) is also increasing. A few newlib functions present in ROM allocate 'struct stat' on the stack and call _fstat_r on this structure. The implementation of fstat is provided in ESP-IDF. This implementation will often do memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting some fields of this structure. If IDF is built with sizeof(st) different from sizeof(st) which ROM was built with, this will lead to an out-of-bounds write and a stack corruption. This commit removes problematic ROM functions from the linker script. Here are the functions which allocate 'struct stat': * _isatty_r (in ROM) * __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and __srefill_r (in ROM) * _fseeko_r (not in ROM) * glob2 (not in ROM) * _gettemp (not in ROM) As a result, these functions are used from libc.a, and use correct size of 'stat' structure. Closes #7980
...and all their callers. With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8, sizeof(struct stat) is also increasing. A few newlib functions present in ROM allocate 'struct stat' on the stack and call _fstat_r on this structure. The implementation of fstat is provided in ESP-IDF. This implementation will often do memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting some fields of this structure. If IDF is built with sizeof(st) different from sizeof(st) which ROM was built with, this will lead to an out-of-bounds write and a stack corruption. This commit removes problematic ROM functions from the linker script. Here are the functions which allocate 'struct stat': * _isatty_r (in ROM) * __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and __srefill_r (in ROM) * _fseeko_r (not in ROM) * glob2 (not in ROM) * _gettemp (not in ROM) As a result, these functions are used from libc.a, and use correct size of 'stat' structure. Closes #7980
Environment
Problem Description
I want to use 64bit wide
time_tin an application. Therefore i followed the instructions to compile the Toolchain from Source and removed--enable-newlib-long-time_tfromcrosstool-NG/samples/xtensa-esp32-elf/crosstool.configleading to the following diff (and a "dirty" compiler version, see above):When compiling the hello world example with
CONFIG_SDK_TOOLCHAIN_SUPPORTS_TIME_WIDE_64_BITS=yin thesdkconfigeverything looks fine.Expected Behavior
I would expect to have the hello world example running as usual.
Actual Behavior
After flashing the application gets stuck in a restart loop:
Steps to reproduce
--enable-newlib-long-time_tas described in the docs).CONFIG_SDK_TOOLCHAIN_SUPPORTS_TIME_WIDE_64_BITS=y, compile with toolchain from step 1 and flash.Additional notes
--enable-newlib-long-time_tand use it for building the hello world example, everything works as expectedThanks in advance!
The text was updated successfully, but these errors were encountered: