Why code is placed into IRAM

[maximkulkin]

Hi.

I'm trying to get a third-party library onto ESP32. I've packaged it as component and it compiles OK. But the problem is when I link everything into a final application, it complains that iram section is overflowed:

xtensa-esp32-elf/bin/ld: my-project.elf section `.iram0.text' will not fit in region `iram0_0_seg'
xtensa-esp32-elf/bin/ld: IRAM0 segment data does not fit.
xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 24384 bytes

I have examined `make size-symbols COMPONENT=my-component` and it shows some functions from that third-party library being placed into IRAM and I have no idea why it does that. I checked linker scripts and found no rule that would have caused that. The third-party component knows nothing about ESP32 architecture and thus does not use any attributes on functions whatsoever. The functions look normal, no special attributes.

Is there a way to figure out why linker decides that way?

[ESP_Angus]

Hi maximkulkin,

That's odd. The linker .map file (in the build directory) may help. This file has a large amount of detail, it's parsed by the "make size" commands to produce the summary output.

If this information is not sensitive, please consider posting the esp32.ld file (from the build directory) and the .map file somewhere so we can take a look at it. If it is sensitive, we can arrange for you to send it to us privately.

[maximkulkin]

Sure, I will attach map file and .ld file. Basically, it's this project: https://github.com/maximkulkin/esp32-ho ... -streaming (notice the branch). I usually edit build/esp32/esp32_out.ld and increase size of iram0_0_seg to get it linked so I can check out component sizes and map file (otherwise it fails to link). Component in question is "x264".

[ESP_Angus]

Thanks for sending all those details. This is a bug in one of the IDF linker scripts when SPIRAM is enabled. The clue is in the linker script map file, where it prints each line of linker command followed by matching sections linked in the binary:

Code: Select all

 *lock.o(.literal .text .literal.* .text.*)
 *fill*         0x0000000040097b15        0x3 
 .text.x264_ctz_4bit
                0x0000000040097b18        0xd /Users/max/Projects/esp/esp32-homekit-camera/build/x264/libx264.a(macroblock.o)

macroblock.o matches *lock.o...

The relevant line is in components/esp32/ld/esp32.spiram.rom-functions-iram.ld

Code: Select all

 *lock.o(.literal .text .literal.* .text.*)

I think someone took a shortcut to avoid having to name multiple different library archives here. Will fix ASAP.

[maximkulkin]

Thank you so much! It all makes sense now.
According to map file doesn't look like this linker instruction does anything useful. Haven't found any other object file matched.

[ESP_Angus]

This linker script is intended to reference object files inside components/newlib/lib/libc-psram-workaround.a - this archive includes a lock.o object file. However it does actually look like this object file is empty!

[ESP_Angus]

Sorry I forgot to update this thread when the issue was fixed:
https://github.com/espressif/esp-idf/co ... 12af8effbb