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.
Hi TI-Experts,
we try to set up an empty CCS Project for the AM243x based on the TI Arm Clang Compiler Tools with C++ support.
Therefore we use:
Steps to reproduce:
1. Import the empty example project from the sdk (mcu_plus_sdk_am243x_08_01_00_36\examples\empty\am243x-lp\r5fss0-0_freertos) into CCS
2. Build the example - success
3. Rename main.c to main.cpp
4. Wrapped everything except the int main() function with extern "C" { }
5. Rebuild the complete project - success
6. Introduced a user class in the C++ area (not extern "C"):
class myClass { public: myClass(){id = -1;} int32_t getID(){return id;} private: int32_t id; };
myClass instance {};
9. Build finished with warnings:
warning #17003-D: relocation to symbol "__TI_exidx_linkto_scn_start_1" overflowed; the 32-bit relocated address 0x8ff58268 is too large to encode in the 31-bit signed PC-Relative field (type = 'R_ARM_PREL31' (42), file = "<internal>", offset = 0x00000000, section = ".ARM.exidx.vectors:freertos.am243x.r5f.ti-arm-clang.debug.lib<HwiP_armv7r_vectors_freertos_asm.obj>")
warning #10015-D: output file "empty_am243x-lp_r5fss0-0_freertos_ti-arm-clang.out" cannot be loaded and run on a target system
-> It is not possible to load or debug the binary.
We checked the TI Arm Clan Compiler Tools User's guide: https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/getting_started_guide/using_the_tools.html# - without success.
In addition, we verified that the "Generate Far Call Trampolines (-trampolines Option) is set.
Question:
Is there a special linker option necessary to link C++ object files?
Thanks in advance
Best regards,
Tommy
I suspect there is a problem in the code generated by the compiler for main.cpp. However, I don't understand it well enough to file a bug report. I have started a conversation with the compiler development team. Please be patient.
Thanks and regards,
-George
Hi there,
we are struggling with the same linker warning. After the update to SDK 08.01.00.36 we get exactly this warning from the linker:
our environment:
We are using the c++ standard C17 in our project. Bye the way, with the previous SDK version 08.01.00.07 and the sysconfig 1.9.0 it worked fine - we could compile, link and run the binary on our board. We have no change in our linker files respectively compiler flags, linker flags. I hope the information helps with troubleshooting.
Kind regards,
Benjamin
with the previous SDK version 08.01.00.07 and the sysconfig 1.9.0 it worked fine
Does this good build use tiarmclang version 1.3.0.LTS? If not, what is the compiler version?
Thanks and regards,
-George
Hey Goerge,
when I undo the following change to the new SDK, it seems to compile successfully for me
--- a/TI_sdk/mcu_plus_sdk_am64x/source/kernel/freertos/dpl/r5/HwiP_armv7r_vectors_freertos_asm.S +++ b/TI_sdk/mcu_plus_sdk_am64x/source/kernel/freertos/dpl/r5/HwiP_armv7r_vectors_freertos_asm.S @@ -33,7 +33,7 @@ .text .global _vectors .type _vectors,%function - .section ".vectors","ax",%progbits + .section ".vectors","aw",%progbits .arm _vectors: LDR pc, reset_addr // Reset @@ -44,7 +44,7 @@ _vectors: LDR pc, reserved_addr // rsvd LDR pc, irq_addr // IRQ LDR pc, fiq_addr // FIQ - +
Thanks! I'll notify the team that is responsible for that SDK.
Thanks and regards,
-George
Tommy, Benjamin,
We're checking into the reason for that modification. Do your C++ programs include exception handling?
We were able to get the program to compile by changing where the ARM.exidx section links. Can you please see if this works for you?
Regards,
Frank
Hi Frank,
no we don't use c++ exception handling in our project (Properties->Build->Arm Compiler->Advanced Options -> C++ excetpin handling: Disabled (-fno-exceptions).
Nevertheless, the provided fix seems to be workable for us. We are able to build and deploy the code :)
Can you please quickly elaborate on the change:
Is it ok if we use the .ARM.exidx: {} palign(8) > R5F_VECS entry global in SECTIONS instead of GROUP in combination with the extension of the R5F_VECS section?
Thanks in advance and best regards,
Tommy
Hi Frank,
Do your C++ programs include exception handling?
not yet
Can you please see if this works for you?
changing the ARM.exidx section in our linker files works for us. So we have no change in SDK.
Thanks a lot,
Benjamin
Hi Tommy,
Can you please quickly elaborate on the change:
I tried leaving all the SECTIONS definitions unchanged, and instead linking the GROUP to R5F_TCMA. This also works, but this isn't a conclusive test since the sizes of .init_array and .fini_array are 0.
I see some description of .init_array here: https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/compiler_manual/runtime_environment/system-initialization-stdz0543503.html#global-constructors
I created a global instance of the class, which results an .init_array of size 8. I then tried linking using both methods:
In both cases, the program was able to link without any warnings. Can you please test this on your side and see if it works?
I'm looping George back into the conversation for further comment.
Regards,
Frank
As far as the compiler is concerned ... The ARM.exidx section should be empty. We are investigating why it is not empty.
Thanks and regards,
-George
Hi Frank,
both cases worked well for me.
Is there a preferred solution (either to extract only .ARM.exidx to R5F_VECS or link the complete GROUP to R5F_TCMA)?
Thanks for your support and best regards,
Tommy
Regarding the compiler problem related to this thread, the issue EXT_EP-10640 has been filed to investigate it. You are welcome to follow it with that link.
Thanks and regards,
-George
Hi Tommy,
From what I can determine by browsing the TI CLANG compiler UG & the web, it appears .ARM.exidx and .init_array/.fini_array are unrelated:
I don't think these sections need to be grouped.
TCMA is a relatively precious (small amount of TCMA compared with MSRAM) fast-memory memory with deterministic access time.
So I think the better solution is to extract .ARM.exidx to R5F_VECS.
Regards,
Frank