ISR stack section adds kilobytes of empty data to binary (IDFGH-7635)

[boarchuz]

Environment

• Module or chip used: ESP32
• IDF version: v5.0-dev-3481-g16a4ee7c36
• Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2022r1-RC1) 11.2.0
• Operating System: Linux
• IDE: VS Code + IDF extension

Problem Description

The FreeRTOS ISR stack is placed in the data section, resulting in kilobytes of zeroes being needlessly embedded in the binary and loaded at startup.

Expected Behavior

Unless there is some performance/initialisation reason not to, this should be placed in bss (or noinit, if possible) for a small but free reduction in binary size.

More Info

Simply changing .data to .section .bss, "aw" here saves ~3kB by default on ESP32 (with CONFIG_FREERTOS_ISR_STACKSIZE=1536 and portNUM_PROCESSORS=2):

esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S

Lines 45 to 54 in 16a4ee7

	.data
	.align 16
	.global port_IntStack
	.global port_switch_flag //Required by sysview_tracing build
	port_IntStack:
	.space configISR_STACK_SIZE*portNUM_PROCESSORS /* This allocates stacks for each individual CPU. */
	port_IntStackTop:
	.word 0
	port_switch_flag:
	.space portNUM_PROCESSORS*4 /* One flag for each individual CPU. */

• As far as I can tell, bss is cleared before FreeRTOS is initialised so this should be fine but I am unsure
• I don't know how to put these in noinit although that seems preferable, at least for port_IntStack
• Can unused port_IntStackTop be removed?

[Dazza0]

@boarchuz Putting it into .bss is fine AFAIK. Strictly speaking, we should be placing the interrupt stacks into one of the .section .dram sections (in case CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY) is enabled.

Can unused port_IntStackTop be removed?

Possibly since it's currently not used. But I assume it was added in case any debugging code can easily access the ISR stack.

I'll get someone to relocate the interrupt stack and tidy up the code.

[boarchuz]

@Dazza0 @o-marshmallow Sorry for the late feedback on this.
I have just noticed that anything with DRAM_ATTR will be placed in DRAM 'data' section (even zero-initialised variables) so, unfortunately, this change has not had the desired effect.
I understand this is a very low priority so I will avoid a new issue but please consider a fix if you see this comment. Thankyou.