This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello,
I modified our linker-script to place specified sections to different addresses. This worked and somehow does not work anymore. When linking I get a warning
line X: warning: no matching section
for multiple libraries and their different sections but ONLY for those libraries at all.
in fact: I am placing sections of 8 libs to different places. that means I place the .text, .rodata, .data of the libraries at different addresses. and only the sections .text, .rodata, .data of three libs are not found anymore. The other libs are fine. I used readelf -t of the LTS1.3.0 (which I use to compile and link) and the sections are definetly there.
example in linkerscript:
SECTIONS { GROUP { .textStack: { -l "examplelib.am243x-bni.r5f.ti-arm-clang.release.lib"(.text) // works -l "examplelib1.am243x-bni.r5f.ti-arm-clang.release.lib"(.text) // does not work } } }
This is a really strange problem since it just does happen out of nowhere. All I did was exchanging the libs with newer ones (but as said: the sections are available).
Do you have any ideas what is happening here and how I can prevent this warning? At first steps it seems the libs are working and the stuff seems to be really linked since I can find the symbols of the libs inside the elf-file and in the debug-image in CCS.
best regards
Felix
ok, my hope that it works anyway is not correct. I get an undefined abort which seems to be caused by the missing sections
Hi Felix,
Can you try the following in your SECTIONS:
.libxxxtext : > MSRAM
{
--library=libxxx.a(.text)
}
I tried the following in the linker.cmd of a CCS project - watchdog_interrupt_am243x-evm_r5fss0-0_nortos_ti-arm-clang. It works OK:
.libctext : > MSRAM
{
--library=libc.a(.text)
}
Refer to TI Linker Command File Primer for details.
Best regards,
Ming
Hey Ming,
I guess we found the problem. It is not located at TI-side. The libs we are using are dependent on each other and it seems that, when building the libs, one lib included all the other libraries. So the symbols were available twice. The linker did not mention that but does just tell that there is no matching section, since it seems he already found that section in the other library.