Page 1 of 1

Why code is placed into IRAM

Posted: Sun Jan 20, 2019 9:53 am
by 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?

Re: Why code is placed into IRAM

Posted: Mon Jan 21, 2019 6:57 am
by 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.

Re: Why code is placed into IRAM

Posted: Mon Jan 21, 2019 7:23 pm
by 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".

Re: Why code is placed into IRAM

Posted: Tue Jan 22, 2019 3:34 am
by 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.

Re: Why code is placed into IRAM

Posted: Wed Jan 23, 2019 6:37 am
by 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.

Re: Why code is placed into IRAM

Posted: Thu Jan 24, 2019 2:08 am
by 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!

Re: Why code is placed into IRAM

Posted: Fri Mar 01, 2019 6:32 am
by ESP_Angus
Sorry I forgot to update this thread when the issue was fixed:
https://github.com/espressif/esp-idf/co ... 12af8effbb