dangerous relocation: l32r: literal target out of range (try using text-section-literals)

[permal]

I'm building from master. Though I haven't pushed the code that causes the linker error to GH yet.

[rudi ;-)]

I'm building from master. Though I haven't pushed the code that causes the linker error to GH yet.

not there it is a must to use IRAM_ATTR and other optimize tricks what IDF has, ( taken from the linked things in first post ) , i did search in the code for this and found (only) 2 things which are land in the IRAM section

sATTR.png (13.82 KiB) Viewed 11014 times

it is not a must to use it - but sometime like igrr wrote you must think over in the project to use it ( better )

when was the build error comes? what did you change from runing build to the error build?
setups in menuconfig different`?

will try to look deeper in the repo next time.
best wishes
rudi

[permal]

The linker error comes with the changed in the first and only commit of this branch: https://github.com/PerMalmberg/IO-Card- ... nker-error.

[permal]

Progress!

Apparently, target_link_options doesn't do what I expect, or I'm using it wrongly.

This doesn't work:

Code: Select all

target_link_options(${PROJECT_NAME} PUBLIC -mlongcalls -mtext-section-literals)

This, however, does:

Code: Select all

if(${ESP_PLATFORM})
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mlongcalls -mtext-section-literals")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mlongcalls -mtext-section-literals")
endif()

Both the C and C++ version has to be set. Note that this is only when building for Xtensa (if you are also compiling for Linux like I am).

Surely modern CMake scripts are not meant to use CMAKE_C_FLAGS directly and instead use target_link_libraries?!

[rudi ;-)]

on your success compile build ( earlier or just now )
can you please run build target size
..make size

and post the info likewise

Code: Select all

Total sizes:
 DRAM .data size:    7848 bytes
 DRAM .bss  size:    4176 bytes
Used static DRAM:   12024 bytes ( 168712 available, 6.7% used)
Used static IRAM:   43124 bytes (  87948 available, 32.9% used)
      Flash code:   81548 bytes
    Flash rodata:   40692 bytes
Total image size:~ 173212 bytes (.bin may be padded larger)

txs

[permal]

make: *** No rule to make target 'size'. Stop.

I think it fails because of similar issues as outlined in this GH issue: https://github.com/espressif/esp-idf/issues/3677 but I haven't managed to figure it out yet.

[rudi ;-)]

make: *** No rule to make target 'size'. Stop.

I think it fails because of similar issues as outlined in this GH issue: https://github.com/espressif/esp-idf/issues/3677 but I haven't managed to figure it out yet.

ok - i see ..

.. can you please make a dump like this and post the success version of you last success build before the problem comes?

run from toolchain and point to the success .elf file you build
example ( i use here a windows pc and looks like this: )

Code: Select all

C:\msys32\opt\xtensa-esp32-elf\bin>xtensa-esp32-elf-objdump -h H:\GEEK2\build\hello-world.elf

result example:

deb_.png (87.29 KiB) Viewed 10985 times

txs

[rudi ;-)]

make: *** No rule to make target 'size'. Stop.

I think it fails because of similar issues as outlined in this GH issue: https://github.com/espressif/esp-idf/issues/3677 but I haven't managed to figure it out yet.

ok -
if you could run the tool from command line
you can use this command: xtensa-esp32-elf-size
and your created .elf file from project

( here i use windows pc, cmd in a window box, cd to the toolchain tools )

Code: Select all

C:\msys32\opt\xtensa-esp32-elf\bin>xtensa-esp32-elf-size H:\GEEK2\build\hello-world.elf

if you have more *.elf for the project you can sum the things like (windows) this

Code: Select all

C:\msys32\opt\xtensa-esp32-elf\bin>xtensa-esp32-elf-size -t H:\GEEK2\build\hello-world.elf H:\GEEK2\build\hello-world-kopie.elf

result then likewise this

deb_2.png (67.24 KiB) Viewed 10980 times

best wishes
rudi

[permal]

Here's the dump as am attached file. 6.5M so a bit too much to post as text.

Size:

text data bss dec hex filename
2060236 812740 32592 2905568 2c55e0 g3
2060236 812740 32592 2905568 2c55e0 (TOTALS)

[rudi ;-)]

txs,

did you start to optimization the code?
further option /

Xtensa Option
-gcc4.1.2

-mtext-section-literals
-mno-text-section-literals
Control the treatment of literal pools. The default is -mno-text-section-literals, which places literals in a separate section in the output file. This allows the literal pool to be placed in a data RAM/ROM, and it also allows the linker to combine literal pools from separate object files to remove redundant literals and improve code size. With -mtext-section-literals, the literals are interspersed in the text section in order to keep them as close as possible to their references. This may be necessary for large assembly files...


further

...where the literals would otherwise be out of range of the L32R instructions in the text section. Literals are grouped into pools following .literal_position directives or preceding ENTRY instructions. These options only affect literals referenced via PC-relative L32R instructions; literals for absolute mode L32R instructions are handled separately. See literal.

btw i am missings this description of Xtensa-Options in ESP-IDF or i did not found/read yet
so i did link to gnu.org and a third , perhabs a good point to point out What to do if we run "literal target out of range"
tips and tricks for code optimization, perhabs a good point for the ESP32 Question section what you mean @esp_igrr,
this can be a new section perhabs in the ESP-IDF about code optimization and perhabs we get code analysis tools

so long, will study the repo,

looks (little usorted unbalanced) big..

text data bss dec hex filename
2060236 812740 32592 2905568 2c55e0 g3
2060236 812740 32592 2905568 2c55e0 (TOTALS)

best wishes
rudi