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.

TI ARM linker rejects ARM "host image" ELF format files generated by the hexpru utility

Other Parts Discussed in Thread: AM3359

CCSv6 TI PRU Cape for Beaglebone Black demo: compilation fails describes a problem where a example program for an AM3359 fails to compile from source. This example has:

- PRU programs compiled by the TI PRU compiler.

- The PRU programs are converted by the hexpru utility into an ARM "host image" ELF format file.

- The ARM "host image" ELF format files generated by the hexpru utility are referenced by the linker command file used by the TI ARM linker.

The problem is that the ARM "host image" ELF format files generated by the hexpru utility are rejected by the TI ARM linker with errors of the following form:

Building target: PRU_Demo.out
Invoking: ARM Linker
"/opt/ti/ti_ccs6_0/ccsv6/tools/compiler/arm_5.1.8/bin/armcl" -mv7A8 --code_state=32 --abi=eabi -me -O2 --define=am3359 --display_error_number --diag_warning=225 --diag_wrap=off -z -m"PRU_Demo.map" --heap_size=0x800 --stack_size=0x800 -i"/opt/ti/ti_ccs6_0/ccsv6/tools/compiler/arm_5.1.8/lib" -i"/opt/ti/ti_ccs6_0/ccsv6/tools/compiler/arm_5.1.8/include" -i"/opt/ti/AM335X_StarterWare_02_00_01_01/binary/armv7a/cgt_ccs/am335x/drivers/Release/" -i"/opt/ti/AM335X_StarterWare_02_00_01_01/binary/armv7a/cgt_ccs/utils/Release/" -i"/opt/ti/AM335X_StarterWare_02_00_01_01/binary/armv7a/cgt_ccs/am335x/beaglebone/platform/Release/" -i"/opt/ti/AM335X_StarterWare_02_00_01_01/binary/armv7a/cgt_ccs/am335x/system_config/Release/" --reread_libs --define=A8_CORE=1 --warn_sections --display_error_number --diag_wrap=off --xml_link_info="PRU_Demo_linkInfo.xml" --rom_model -o "PRU_Demo.out" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_Audio/Debug/PRU_Audio_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_HDQ_TempSensor0/Debug/PRU_HDQ_TempSensor0_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_HDQ_TempSensor1/Debug/PRU_HDQ_TempSensor1_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_Hardware_UART/Debug/PRU_Hardware_UART_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_LED0/Debug/PRU_LED0_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_LED1/Debug/PRU_LED1_image.obj" "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_Switch/Debug/PRU_Switch_image.obj" "./pru.obj" "./pru_cape_demo.obj" "../pru_cape_demo.cmd" -l"rtsv7A8_A_le_eabi.lib" -l"drivers.lib" -l"utils.lib" -l"system.lib" -l"platform.lib"
<Linking>
fatal error #10183: --abi=eabi is incompatible with file "/home/Mr_Halfword/pru-software-support-package-pru-software-support-package/pru_cape/pru_fw/PRU_Audio/Debug/PRU_Audio_image.obj" (TIABI v0)
gmake: *** [PRU_Demo.out] Error 1

Running armofd on the ARM "host image" ELF format files generated by hexpru doesn't show a ".ARM.attributes" section. Is it the lack of a ".ARM.attributes" section which causes the ARM linker to assume the file is in TIABI_v0 format and therefore incompatible with the --abi=eabi ARM executable which is being generated?

  • Unfortunately, the expert I need to consult has left for the holidays.  I'm not sure when I will be able to address this issue.  It will probably be after the holidays.

    Thanks and regards,

    -George

  • Chester Gillon said:
    CCSv6 TI PRU Cape for Beaglebone Black demo: compilation fails describes a problem where a example program for an AM3359 fails to compile from source.

    Chester Gillon said:
    Is it the lack of a ".ARM.attributes" section which causes the ARM linker to assume the file is in TIABI_v0 format and therefore incompatible with the --abi=eabi ARM executable which is being generated?
    I have updated the referenced thread to say the linker error goes away if the order of the object files given to the linker is changed, such that the first object file is one generated by the ARM compiler rather than the hexpru utility.

    i.e. the problem appears related to the order in which the ARM linker processes object files, rather than the lack of ".ARM.attributes" in the ARM "host image" ELF format files generated by hexpru.

  • I apologize for the delay.

    Thank you for notifying us about this problem.  I can reproduce this failed link, even with a very small test case.  I filed SDSCM00051482 in the SDOWP system to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George