RM48L952: Link time compatibility between threadx library (built using ARM FuSa Compiler tools 6.16.2) and TI code build using TI ARM tools ti-cfg-arm_20.2.7.LTS

Kip Leitner

Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN, DP83640

Tool/software:

My goal is to link a library built with ARM FuSa tools into an application built with TI ARM compiler tools.

Using TI ARM tools ti-cfg-arm_20_2_7.LTS, I'm attempting -- and failing -- an ordinary link using of threadx library (built using ARM FuSa tools 6.16.2) and some TI HalCoGen code and C/C++ application code. Both builds work independently. The TI code runs successfully on the ARM HDK. However when I include the threadx_XDER.a library file built with ARM FuSa tools, the TI linker complains and errors (see below). As a restricted capabilities test, I am using the flag --retain with the TI linker to try to force it to retain one of the object files in the threadx_XDER.a library, but get the error:

##################################################

**** Build of configuration Debug for project Config_01_POC ****

"C:\\ti\\ccs1240\\ccs\\utils\\bin\\gmake" -k -j 20 all -O

Building target: "Config_01_POC.out" <*** Successfully completed all compiles ***>
Invoking: Arm Linker
"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 -me --opt_for_speed=1 --define=XDER_COMPILER_TI_20_2_7_LTS --define=CCS --define=_AEABI_PORTABILITY_LEVEL=1 --define=FPU_PRESENT -g --symdebug:dwarf_version=4 --c11 --diag_wrap=off --display_error_number --issue_remarks --unaligned_access=on --enum_type=packed --wchar_t=16 --common=on --asm_define=__TI_EABI_ASSEMBLER --check_misra="2,-2.2,3,4,6.1,6.2,6.4,6.5,7.1,8,-8.7,-8.12,9,10,-10.1,-10.3,-10.5,-10.6,11,-11.3,-11.4,-11.5,12,-12.1,-12.4,-12.6,-12.7,13,14,15,16,-16.3,-16.7,17,-17.4,18,-18.4,19,-19.4,-19.7,-19.10,-19.12,-19.13,20,-20.1,-20.2,-20.9,-20.11" --misra_advisory=remark --misra_required=error -z -m"Config_01_POC.map" --heap_size=0x1000 --stack_size=0x1000 -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/lib" -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/include" --reread_libs --disable_auto_rts --diag_remark=1401 --diag_remark=179 --diag_remark=552 --diag_suppress=552 --diag_suppress=179 --diag_wrap=off --display_error_number --issue_remarks --verbose_diagnostics --warn_sections --generate_dead_funcs_list=dead_func_XDER.txt --xml_link_info="Config_01_POC_linkInfo.xml" --retain=threadx_XDER.a<tx_byte_allocate.o> --fill_value=0xfacedeed --rom_model --compress_dwarf=off -o "Config_01_POC.out" "./Config_01_POC_HAL/source/adc.obj" "./Config_01_POC_HAL/source/can.obj" "./Config_01_POC_HAL/source/crc.obj" "./Config_01_POC_HAL/source/dabort.obj" "./Config_01_POC_HAL/source/dcc.obj" "./Config_01_POC_HAL/source/dmm.obj" "./Config_01_POC_HAL/source/emac.obj" "./Config_01_POC_HAL/source/emif.obj" "./Config_01_POC_HAL/source/errata_SSWF021_45.obj" "./Config_01_POC_HAL/source/esm.obj" "./Config_01_POC_HAL/source/gio.obj" "./Config_01_POC_HAL/source/het.obj" "./Config_01_POC_HAL/source/i2c.obj" "./Config_01_POC_HAL/source/lin.obj" "./Config_01_POC_HAL/source/mdio.obj" "./Config_01_POC_HAL/source/mibspi.obj" "./Config_01_POC_HAL/source/notification.obj" "./Config_01_POC_HAL/source/phy_dp83640.obj" "./Config_01_POC_HAL/source/pinmux.obj" "./Config_01_POC_HAL/source/pom.obj" "./Config_01_POC_HAL/source/rti.obj" "./Config_01_POC_HAL/source/rtp.obj" "./Config_01_POC_HAL/source/sci.obj" "./Config_01_POC_HAL/source/spi.obj" "./Config_01_POC_HAL/source/sys_core.obj" "./Config_01_POC_HAL/source/sys_dma.obj" "./Config_01_POC_HAL/source/sys_intvecs.obj" "./Config_01_POC_HAL/source/sys_main.obj" "./Config_01_POC_HAL/source/sys_mpu.obj" "./Config_01_POC_HAL/source/sys_pcr.obj" "./Config_01_POC_HAL/source/sys_phantom.obj" "./Config_01_POC_HAL/source/sys_pmm.obj" "./Config_01_POC_HAL/source/sys_pmu.obj" "./Config_01_POC_HAL/source/sys_selftest.obj" "./Config_01_POC_HAL/source/sys_startup.obj" "./Config_01_POC_HAL/source/sys_vim.obj" "./Config_01_POC_HAL/source/system.obj" "./HET_IslandDER_01/HET_IslandDER_01.obj" "./XDER_code/source_XDER/adc_XDER.obj" "./XDER_code/source_XDER/ems.obj" "./XDER_code/source_XDER/gio_int_handler.obj" "./XDER_code/source_XDER/helpers_xder.obj" "./XDER_code/source_XDER/het_XDER.obj" "./XDER_code/source_XDER/rti_int_handler.obj" "./XDER_code/source_XDER_threadx_demo/threadx_demo.obj" "../Config_01_POC_HAL/source/sys_link.cmd" -l"C:/Users/Kip_Leitner/workspace_v12/Config_01_POC/Debug/rtsv7R4_A_le_v3D16_eabi_debug.lib" -l"C:/ti/Hercules/Cortex-R4 CMSIS DSP Library/1.0.0/Lib/ti_math_Cortex_R4_lspf.lib" -l"C:/Users/Kip_Leitner/Development Studio Workspace/threadx_XDER/Debug/threadx_XDER.a"
makefile:187: recipe for target 'Config_01_POC.out' failed
gmake[1]: *** [Config_01_POC.out] Error 1
makefile:183: recipe for target 'all' failed
gmake: *** [all] Error 2

**** Build Finished ****

Here's the makefile contents:

# All Target
all: $(OBJS) $(CMD_SRCS) $(GEN_CMDS)
<line 183>@$(MAKE) --no-print-directory -Onone "Config_01_POC.out"

# Tool invocations
Config_01_POC.out: $(OBJS) $(CMD_SRCS) $(GEN_CMDS)
<line 187>@echo 'Building target: "$@"'
@echo 'Invoking: Arm Linker'
"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 -me --opt_for_speed=1 --define=XDER_COMPILER_TI_20_2_7_LTS --define=CCS --define=_AEABI_PORTABILITY_LEVEL=1 --define=FPU_PRESENT -g --symdebug:dwarf_version=4 --c11 --diag_wrap=off --display_error_number --issue_remarks --unaligned_access=on --enum_type=packed --wchar_t=16 --common=on --asm_define=__TI_EABI_ASSEMBLER --check_misra="2,-2.2,3,4,6.1,6.2,6.4,6.5,7.1,8,-8.7,-8.12,9,10,-10.1,-10.3,-10.5,-10.6,11,-11.3,-11.4,-11.5,12,-12.1,-12.4,-12.6,-12.7,13,14,15,16,-16.3,-16.7,17,-17.4,18,-18.4,19,-19.4,-19.7,-19.10,-19.12,-19.13,20,-20.1,-20.2,-20.9,-20.11" --misra_advisory=remark --misra_required=error -z -m"Config_01_POC.map" --heap_size=0x1000 --stack_size=0x1000 -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/lib" -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/include" --reread_libs --disable_auto_rts --diag_remark=1401 --diag_remark=179 --diag_remark=552 --diag_suppress=552 --diag_suppress=179 --diag_wrap=off --display_error_number --issue_remarks --verbose_diagnostics --warn_sections --generate_dead_funcs_list=dead_func_XDER.txt --xml_link_info="Config_01_POC_linkInfo.xml" --retain=threadx_XDER.a<tx_byte_allocate.o> --fill_value=0xfacedeed --rom_model --compress_dwarf=off -o "Config_01_POC.out" $(ORDERED_OBJS)
@echo 'Finished building target: "$@"'
@echo ' '

###########################################

To be absolutely clear, the build of threadx under ARM FuSa works fine. The build of HALCoGen code + my Application code in C and C++ goes fine -- and executes fine. But when I try to link the threadx library into my 20.2.7_LTS build, the build fails. All that gets added is this line:

-l"C:/Users/Kip_Leitner/Development Studio Workspace/threadx_XDER/Debug/threadx_XDER.a

Also, to compare ABI tags, using WSL, I used Linux readelf to dump the ELF information on (a) the threadx_XDER.a library and (b) the final *.out file built with TI tools WITHOUT trying to link the library. Here are the tag differences (left on is ARM FuSa compiler, right is TI 20.2.7_LTS). don't know how to make all the Tags the same, but it seems like both compilers are configured to produce compatible binary outputs.

I'm not sure what might be wrong. Can you help? I've been working on this for three days now.

over 1 year ago

0 QJ Wang over 1 year ago

TI__Guru**** 196306 points

Hi Kip,

I will forward your question to TI compiler team.

0 Kip Leitner over 1 year ago

Prodigy 196 points

readelf_a_threadx_xder.a.txt Uploading the ELF attributes of threadx compiles as library using ARM FuSa tools, created using "readelf -a <filename>

0 Kip Leitner over 1 year ago

Prodigy 196 points

In order to help everyone understand the priority of this issue, I have been authorized by my management to disclose the information that in FY25, pending the successful completion of the testing of code in FY24, my company is scheduled to purchase up to 30,000 Hercules class processors from Texas Instruments. Critical to this effort is knowing if there is a success path to linking threadx built with ARM FuSa compiler tools into the image built with TI 20.2.7_LTS tools. I asked the ARM team if their own FuSa tool chain is compatible with their own ARM AEABI specifications. They said yes, so if that is true, then either I am not configuring something correctly in one or both of the tool chains, or the 20.2.7_LTS linker is having trouble with ELF Generated by ARM FuSa 6.16.2

Further, threadx is only compliant with Functional Safety (FS) Specification 60730 if built under one of the certified compilers. Because the threadx build system was never ported to the TI LTS series of compilers, there is no other way (other than the huge effort of porting threadx itself and recertifying compliant with 60730 tool chain, itself a gigantic effort), that we can include this essential component in the build. We need both the TI HALCoGen and FS library code for our App as well as threadx, so we're depending on the LTS linker to succeed in the link.

0 George Mock over 1 year ago in reply to Kip Leitner

TI__Guru**** 249260 points

TI does not test linking with code built by the ARM FuSa compiler. I'm not aware of anyone who has ever done it.

The link fails, with no diagnostics at all? Are you sure? Does the linker generate any files, such as the .out file, or .map file?

Consider this experiment. Write a small program that has one source file. It has a main function that calls one function from the threadx library. This is a build only experiment which does not run. Build the one source file as you do with the TI Arm compiler. Link it with the threadx library. What happens?

Thanks and regards,

-George

0 George Mock over 1 year ago in reply to George Mock

TI__Guru**** 249260 points

In case it helps, all the Arm attributes such as Tag_ABI_PCS_R9_use, are described in this specification maintained by Arm.

Thanks and regards,

-George

0 Kip Leitner over 1 year ago in reply to George Mock

Prodigy 196 points

George, I've read through parts of many of these ABI specs looking at the Tags. I think, at the end of the day, success in linking will be defined by the following

modifying ARM FuSa build configuration options to try to find minimum basic subset that the TI LTS linker can understand
Finding out how to configure the LTS compiler to use configuration options compatible with ARM FuSa compiler options.

I'm still hopeful this can work. For instance the ARM DSP lib linked in just fine, no problems there, so we know that at least one externally built libs work just fine.

Now, I'm writing up for you an experiment I did a couple days ago with "simple use case" -- very similar to what you suggested. It will take me a while to post details. After that, I'll run the exact experiment you think. I think that is a really good idea, simplifying everything to see if something basic works. I got lost in the weeds -- should have done this a few days ago.

It would be nice if one of the TI LTS compiler guys could look at these Tags. I know that at one time (and maybe still is) there was big intelligence inside the TI compiler team on the Tags because in order to get the simple link of threadx (which I will describe below) to work at all, I had to massage the ARM FuSa build in various ways to get rid of errors based on "wchar_t size" and "enum size" and "VFP Settings" and other stuff. If the lib threadx_XDER.a doesn't have all these set the same as the TI LTS compiler, then at link time the LTS linker absolute, accurately, detects this problem in great detail and tells you exactly what it is. So it seems that there is some sense that interoperability was a goal, at least for very simple link issues, otherwise you couldn't use external libraries at all.

Contrarily, suppose that all the TI intelligence in detecting tags is meant ONLY for detecting tags that are different in TI LTS code, and not other vendor code, and the detection code just "happens" to also work with ARM FuSa generated ELF code. Then, we might be in a situation where even if I get all the ARM build configs right so that the lib is built with the perfect equivalent set of Tags matching what the TI LTS linker is looking for, the link will still fail. I was wondering if there is anyone at TI who could answer this pretty simple question? Will it NEVER WORK, or is there a good chance it might if simply adjust more tags. It's a lot of work for me to try all these different compile options, hoping to hit the jackpot.

I'll start my next post for the previous experiment.

0 Kip Leitner over 1 year ago in reply to Kip Leitner

Prodigy 196 points

FWIW, when I do my "Big Experiment" which I listed above, when the linker terminates, no *.obj and no *.map file are produced.

TI notes that using ARM industry standard ABIv2 should result in successful linking of objects built with different tool chains. From TI's Compiler Manual:

0 George Mock over 1 year ago in reply to Kip Leitner

TI__Guru**** 249260 points

There is another factor you have not considered: the Dwarf debug information. The Dwarf spec is very flexible. You can say the same thing multiple ways. It is possible the FuSa toolchain emits Dwarf in some way that meets the spec, but the TI linker still mishandles it. This escaped testing because the TI toolchain simply never emits Dwarf like the FuSa toolchain does. The lack of any diagnostic before failure is what makes me think this may be happening.

I don't have a good suggestion at this point. I just want to let you know what I am thinking.

Thanks and regards,

-George

0 George Mock over 1 year ago in reply to George Mock

TI__Guru**** 249260 points

Have you tried ...

George Mock said:
Consider this experiment. Write a small program that has one source file. It has a main function that calls one function from the threadx library. This is a build only experiment which does not run. Build the one source file as you do with the TI Arm compiler. Link it with the threadx library.

If so, what happened?

Thanks and regards,

-George

0 Kip Leitner over 1 year ago in reply to George Mock

Prodigy 196 points

Summary:

Two things. I did the experiment you suggested. (1) Linker errors relating to FP tags. (2) I did my own experiment and got a limited linker success linking threadx. This is very good.

Details:

(1) Your experiment. The link failed with floating point Tag_ABI compatibility issues. The TI linker looks to be broken, because it says certain threadx files have Tags related to the floating point which are incompatible with other Floating Point (FP) tags, but in fact, if you use readelf to dump the ABI Tags from the threadx library, the tags referred to in the build output errors from TI do not in fact actually exist in the threadx library. In fact these tags are completely non-existence in the threadx lib modules in question. However, it might be something else is wrong and the diagnostic is spurious.

(2) However, Using single file main() sample Application (No HAL Code), I did (finally) get a successful (unusable binary) link with threadx like this:

Threadx: Thumb, No floating Point, No Debug Info, Big Endian
TI RTS Lib: Pre-built by TI, Thumb, Big Endian, C:\ti . . . \ti-cgt-arm_20.2.7.LTS\lib\rtsv7R4_T_be_eabi.lib
Application: Single main() function built : Thumb, Big Endian, no debug, No floating point.

-------------------

(3) I built the ordinary library which does not come with CCS: rtsv7R4_A_le_eabi.lib. The following successfully links:

Threadx: No floating Point, No Debug Info, Little Endian
TI RTS Lib: Build by me using TI build tools: rtsv7R4_A_le_eabi.lib
Application: Single main() function built : Little Endian, no debug, No floating point.

------------------

(4) With the skeleton main program, successfully linked the following with these attributes: ARM state, little endian, debug, no floating point

Threadx
TI RTS Lib
Application: Single main() function

------------------

(5) With the skeleton main program, successfully linked the following with these attributes: ARM state, little endian, debug, floating point

Threadx
TI RTS Lib
Application: Single main() function

------------------

I read that TI compiler is End-of-Life and I am concerned I will not be able to use TI hardware because tool chain has limited support. Can you speak to this? Is there any support internal to TI for the 20.2.7_LTS for Arm targets?

0 George Mock over 1 year ago in reply to Kip Leitner

TI__Guru**** 249260 points

Kip Leitner said:
I read that TI compiler is End-of-Life and I am concerned I will not be able to use TI hardware because tool chain has limited support. Can you speak to this?

See the note near the end of the opening page of the tiarmclang online manual. The final series of releases for the TI Arm (not clang) compiler is 20.2.x.LTS. The latest of that series is version 20.2.7.LTS. It released about 2 years ago. Will there ever be a version 20.2.8.LTS? There is not much pressure for it now. As time goes on, it becomes less and less likely.

Thanks and regards,

-George

0 Kip Leitner over 1 year ago in reply to George Mock

Prodigy 196 points

OK George. I have resolved the issue.

Summary:

In certain situations, the TI Linker 20.2.7_LTS does not correctly link AEABI compatible ELF files which have sections where the tag Tag_ABI_VFP_args is defined to a specific value and other sections in the ELF file do not have the tag defined at all.

People interested in linking 3rd party libraries to compatible with objects built with the TI 20.2.7_LTS tools chain should read this post to understand how to force the TI linker to link AEABI compatible objects whose tags are not processed as expected by TI Compiler 20.2.7_LTS. The details and insights of this post probably apply to all versions of the TI LTS compiler released in the last 10 years.

The case in point involves the tag Tag_ABI_VFP_args, which indicates how compilers should generate code compatible with the ARM ABI.

Details:

The RTOS threadx, version 6.1.1, when built with ARM DS 6 tools is compatible with the ARM AEABI standard but the TI linker 20.2.7_LTS handles the floating point tag Tag_ABI_VFP_args in a highly restricted, unusual way, not according to the recommendations in ARM's AEABI standard.

George Mott investigated this problem 10 years ago for TI, where another customer had the exact same issue:

Linking compatible ELF files with tag Tag_ABI_VFP_args

George Mott also did more work advising how to groom the ABI tags related to VFP (vector floating point) unit:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/699187/compiler-tm4c1290ncpdt-gcc---asm-to-ti---ccs

Root Cause Examination:

The purpose of Tags, describe in ARM's AEABI documents, is here:

ARM ABI (Section 5.3.6)

(excerpt)

It is required that:

Attributes that record facts about the compatibility of this relocatable file with other relocatable files are recorded in the public "aeabi" subsection.
Attributes meaningful only to the producer are recorded in the private vendor subsection. These must not affect compatibility between relocatable files unless that is recorded in the "aeabi" subsection using generic compatibility tags.
Generic compatibility tags must record a "safe" approximation. A toolchain may record more precise information that only that toolchain comprehends.

Note

The intent is that a "foreign" toolchain should not mistakenly link incompatible binary files. The consequence is that a foreign toolchain might sometimes refuse to link files that could be safely linked, because their incompatibility has been crudely approximated.

Futher, the meaning of the tags related to the floating point is a follows:

Tag_ABI_VFP_args, (=28), uleb128
    0  The user intended FP parameter/result passing to conform to AAPCS, base variant
    1  The user intended FP parameter/result passing to conform to AAPCS, VFP variant
    2  The user intended FP parameter/result passing to conform to toolchain-specific
       conventions
    3  Code is compatible with both the base and VFP variants; the user did not permit
       non-variadic functions to pass FP parameters/results

When linking, the TI Linker notes 6 files in the threadx library have incompatible tags. (for clarity, only the first file the TI Linker complains about is shown below)

"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 -me --opt_for_speed=1 --define=XDER_COMPILER_TI_20_2_7_LTS --define=CCS --define=_AEABI_PORTABILITY_LEVEL=1 --define=FPU_PRESENT -g --c11 --diag_wrap=off --display_error_number --issue_remarks --verbose_diagnostics --unaligned_access=on --enum_type=packed --wchar_t=16 --common=on --asm_define=__TI_EABI_ASSEMBLER --check_misra="2,-2.2,3,4,6.1,6.2,6.4,6.5,7.1,8,-8.7,-8.12,9,10,-10.1,-10.3,-10.5,-10.6,11,-11.3,-11.4,-11.5,12,-12.1,-12.4,-12.6,-12.7,13,14,15,16,-16.3,-16.7,-16.9,17,-17.4,18,-18.4,19,-19.4,-19.7,-19.10,-19.12,-19.13,20,-20.1,-20.2,-20.9,-20.11" --misra_advisory=remark --misra_required=error -z -m"Config_01_POC.map" --heap_size=0x1000 --stack_size=0x1000 -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/lib" -i"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/include" --reread_libs --disable_auto_rts --diag_remark=179 --diag_remark=552 --diag_remark=1401 --diag_suppress=179 --diag_suppress=552 --diag_wrap=off --display_error_number --issue_remarks --verbose_diagnostics --warn_sections --xml_link_info="Config_01_POC_linkInfo.xml" --fill_value=0xfacedeed --rom_model --compress_dwarf=off -o "Config_01_POC.out" "./Config_01_POC_HAL/source/adc.obj" "./Config_01_POC_HAL/source/can.obj" "./Config_01_POC_HAL/source/crc.obj" "./Config_01_POC_HAL/source/dabort.obj" "./Config_01_POC_HAL/source/dcc.obj" "./Config_01_POC_HAL/source/dmm.obj" "./Config_01_POC_HAL/source/emac.obj" "./Config_01_POC_HAL/source/emif.obj" "./Config_01_POC_HAL/source/errata_SSWF021_45.obj" "./Config_01_POC_HAL/source/esm.obj" "./Config_01_POC_HAL/source/gio.obj" "./Config_01_POC_HAL/source/het.obj" "./Config_01_POC_HAL/source/i2c.obj" "./Config_01_POC_HAL/source/lin.obj" "./Config_01_POC_HAL/source/mdio.obj" "./Config_01_POC_HAL/source/mibspi.obj" "./Config_01_POC_HAL/source/notification.obj" "./Config_01_POC_HAL/source/phy_dp83640.obj" "./Config_01_POC_HAL/source/pinmux.obj" "./Config_01_POC_HAL/source/pom.obj" "./Config_01_POC_HAL/source/rti.obj" "./Config_01_POC_HAL/source/rtp.obj" "./Config_01_POC_HAL/source/sci.obj" "./Config_01_POC_HAL/source/spi.obj" "./Config_01_POC_HAL/source/sys_core.obj" "./Config_01_POC_HAL/source/sys_dma.obj" "./Config_01_POC_HAL/source/sys_intvecs.obj" "./Config_01_POC_HAL/source/sys_main.obj" "./Config_01_POC_HAL/source/sys_mpu.obj" "./Config_01_POC_HAL/source/sys_pcr.obj" "./Config_01_POC_HAL/source/sys_phantom.obj" "./Config_01_POC_HAL/source/sys_pmm.obj" "./Config_01_POC_HAL/source/sys_pmu.obj" "./Config_01_POC_HAL/source/sys_selftest.obj" "./Config_01_POC_HAL/source/sys_startup.obj" "./Config_01_POC_HAL/source/sys_vim.obj" "./Config_01_POC_HAL/source/system.obj" "./HET_IslandDER_01/HET_IslandDER_01.obj" "./XDER_code/source_XDER/adc_XDER.obj" "./XDER_code/source_XDER/ems.obj" "./XDER_code/source_XDER/gio_int_handler.obj" "./XDER_code/source_XDER/helpers_xder.obj" "./XDER_code/source_XDER/het_XDER.obj" "./XDER_code/source_XDER/rti_int_handler.obj" "./XDER_code/source_XDER_threadx_demo/threadx_demo.obj" "../Config_01_POC_HAL/source/sys_link.cmd" -l"C:/ti/ccs1240/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/lib/rtsv7R4_A_le_v3D16_eabi.lib" -l"C:/ti/Hercules/Cortex-R4 CMSIS DSP Library/1.0.0/Lib/ti_math_Cortex_R4_lspf.lib" -l"C:/Users/Kip_Leitner/Development Studio Workspace/threadx_XDER_611/Debug/threadx_XDER_611_le_debug_g3_fp_hardware.a"
<Linking>
error #16004-D: file "C:/Users/Kip_Leitner/Development Studio Workspace/threadx_XDER_611/Debug/threadx_XDER_611_le_debug_g3_fp_hardware.a<tx_initialize_low_level.o>" has a Tag_ABI_VFP_args attribute value of "0" that is different than one previously seen ("1"); combining incompatible files

However, if we use linux utility readelf to examine this object file in the library, we see that, in fact, object file <tx_initialize_low_level.o> does not contain the tag "Tag_ABI_VFP_args".

kleitner@xDER-kleitner-2:/mnt/c/Users/Kip_Leitner/Development Studio Workspace/threadx_XDER_611/Debug$ readelf -a threadx_XDER_611_le_debug_g3_fp_hardware.a | grep -A 137 "tx_initialize_low_level.o"
File: threadx_XDER_611_le_debug_g3_fp_hardware.a(tx_initialize_low_level.o)
ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class:                             ELF32
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              REL (Relocatable file)
Machine:                           ARM
Version:                           0x1
Entry point address:               0x0
Start of program headers:          0 (bytes into file)
Start of section headers:          2368 (bytes into file)
Flags:                             0x5000000, Version5 EABI
Size of this header:               52 (bytes)
Size of program headers:           0 (bytes)
Number of program headers:         0
Size of section headers:           40 (bytes)
Number of section headers:         13
Section header string table index: 1

Section Headers:
[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
[ 0]                   NULL            00000000 000000 000000 00      0   0 0
[ 1] .strtab           STRTAB          00000000 0006fc 000242 00      0   0 1
[ 2] .text             PROGBITS        00000000 000034 000090 00 AX 0   0 4
[ 3] .rel.text         REL             00000000 0005f4 000078 08     12   2 4
[ 4] .ARM.attributes   ARM_ATTRIBUTES 00000000 0000c4 00002a 00      0   0 1
[ 5] .debug_info       PROGBITS        00000000 0000ee 000266 00      0   0 1
[ 6] .rel.debug_info   REL             00000000 00066c 000078 08     12   5 4
[ 7] .debug_abbrev     PROGBITS        00000000 000354 000021 00      0   0 1
[ 8] .debug_aranges    PROGBITS        00000000 000375 000020 00      0   0 1
[ 9] .rel.debug_a[...] REL             00000000 0006e4 000010 08     12   8 4
[10] .debug_line       PROGBITS        00000000 000395 00009d 00      0   0 1
[11] .rel.debug_line   REL             00000000 0006f4 000008 08     12 10 4
[12] .symtab           SYMTAB          00000000 000434 0001c0 10      1   8 4
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), y (purecode), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

Relocation section '.rel.text' at offset 0x5f4 contains 15 entries:
Offset     Info    Type            Sym.Value Sym. Name
0000001c 0000131d R_ARM_JUMP24      0000001c   __tx_undefined
00000020 0000121d R_ARM_JUMP24      00000020   __tx_swi_interrupt
00000024 0000101d R_ARM_JUMP24      00000024   __tx_prefetch_handler
00000028 00000b1d R_ARM_JUMP24      00000028   __tx_abort_handler
0000002c 0000111d R_ARM_JUMP24      0000002c   __tx_reserved_handler
00000030 0000181d R_ARM_JUMP24      00000000   _tx_thread_contex[...]
00000050 00001a1c R_ARM_CALL        00000000   _tx_timer_interrupt
0000005c 0000171d R_ARM_JUMP24      00000000   _tx_thread_contex[...]
00000060 00000d1d R_ARM_JUMP24      00000060   __tx_fiq_handler
00000074 00000902 R_ARM_ABS32       00000000   Image$$SVC_STACK$[...]
00000078 00001902 R_ARM_ABS32       00000000   _tx_thread_system[...]
0000007c 00000802 R_ARM_ABS32       00000000   Image$$DATA$$ZI$$Limit
00000080 00001602 R_ARM_ABS32       00000000   _tx_initialize_un[...]
00000088 00001402 R_ARM_ABS32       00000000   _tx_build_options
0000008c 00001b02 R_ARM_ABS32       00000000   _tx_version_id

Relocation section '.rel.debug_info' at offset 0x66c contains 15 entries:
Offset     Info    Type            Sym.Value Sym. Name
00000006 00000602 R_ARM_ABS32       00000000   .debug_abbrev
0000000c 00000702 R_ARM_ABS32       00000000   .debug_line
00000010 00000402 R_ARM_ABS32       00000000   .text
00000014 00000402 R_ARM_ABS32       00000000   .text
00000111 00000402 R_ARM_ABS32       00000000   .text
0000012c 00000402 R_ARM_ABS32       00000000   .text
0000014b 00000402 R_ARM_ABS32       00000000   .text
0000016d 00000402 R_ARM_ABS32       00000000   .text
0000018c 00000402 R_ARM_ABS32       00000000   .text
000001ae 00000402 R_ARM_ABS32       00000000   .text
000001cb 00000402 R_ARM_ABS32       00000000   .text
000001f2 00000402 R_ARM_ABS32       00000000   .text
00000216 00000402 R_ARM_ABS32       00000000   .text
00000244 00000402 R_ARM_ABS32       00000000   .text
00000261 00000402 R_ARM_ABS32       00000000   .text

Relocation section '.rel.debug_aranges' at offset 0x6e4 contains 2 entries:
Offset     Info    Type            Sym.Value Sym. Name
00000006 00000502 R_ARM_ABS32       00000000   .debug_info
00000010 00000402 R_ARM_ABS32       00000000   .text

Relocation section '.rel.debug_line' at offset 0x6f4 contains 1 entry:
Offset     Info    Type            Sym.Value Sym. Name
0000006b 00000402 R_ARM_ABS32       00000000   .text

There are no unwind sections in this file.

Symbol table '.symtab' contains 28 entries:
   Num:    Value Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE LOCAL DEFAULT UND
     1: 00000000     0 NOTYPE LOCAL DEFAULT    2 $a.0
     2: 00000074     0 NOTYPE LOCAL DEFAULT    2 $d.1
     3: 00000054     0 NOTYPE LOCAL DEFAULT    2 _tx_not_timer_in[...]
     4: 00000000     0 SECTION LOCAL DEFAULT    2 .text
     5: 00000000     0 SECTION LOCAL DEFAULT    5 .debug_info
     6: 00000000     0 SECTION LOCAL DEFAULT    7 .debug_abbrev
     7: 00000000     0 SECTION LOCAL DEFAULT   10 .debug_line
     8: 00000000     0 NOTYPE GLOBAL DEFAULT UND Image$$DATA$$ZI$[...]
     9: 00000000     0 NOTYPE GLOBAL DEFAULT UND Image$$SVC_STACK[...]
    10: 00000000     0 NOTYPE GLOBAL DEFAULT UND __main
    11: 00000028     0 FUNC    GLOBAL DEFAULT    2 __tx_abort_handler
    12: 00000060     0 FUNC    GLOBAL DEFAULT    2 __tx_example_vec[...]
    13: 00000060     0 FUNC    GLOBAL DEFAULT    2 __tx_fiq_handler
    14: 00000030     0 FUNC    GLOBAL DEFAULT    2 __tx_irq_handler
    15: 00000034     0 FUNC    GLOBAL DEFAULT    2 __tx_irq_process[...]
    16: 00000024     0 FUNC    GLOBAL DEFAULT    2 __tx_prefetch_handler
    17: 0000002c     0 FUNC    GLOBAL DEFAULT    2 __tx_reserved_handler
    18: 00000020     0 FUNC    GLOBAL DEFAULT    2 __tx_swi_interrupt
    19: 0000001c     0 FUNC    GLOBAL DEFAULT    2 __tx_undefined
    20: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_build_options
    21: 00000000     0 FUNC    GLOBAL DEFAULT    2 _tx_initialize_l[...]
    22: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_initialize_u[...]
    23: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_thread_conte[...]
    24: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_thread_conte[...]
    25: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_thread_syste[...]
    26: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_timer_interrupt
    27: 00000000     0 NOTYPE GLOBAL DEFAULT UND _tx_version_id

No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "cortex-r4f"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Realtime
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_CPU_unaligned_access: v6

Options for this tag (IF IT IS SET) are defined in the ARM compiler reference manual like this:

-mfloat-abi=value, where value is one of:

soft -- Software library functions for floating-point operations and software floating-point linkage.
softfp -- Hardware floating-point instructions and software floating-point linkage.
hard -- Hardware floating-point instructions and hardware floating-point linkage.

The reasonable assumption a linker should make -- when the the tag is not present, and hence undefined -- would be to assume that the module does not use floating point, so defining the tag is not necessary. However, the TI linker assumes, because OTHER FILES in the library have this tag set, that there is a compatibility error, which is not true.

However, common sense would argue that if the floating point tag is present Tag_FP_arch: VFPv3-D16, but the tag Tag_ABI_VFP_args is not, then this means there is no floating point code in the module. THIS IS THE CASE WITH THESE MODULES in threadx.a.

In fact, there is no floating point vars or arithmetic ANYWHERE in threadx. So, TI LTS linker behavior is strange here.

Workarounds. In ARM FuSa compiler we can set the tag as an assembler directive to get around this problem so the threadx lib objects are compatible with the way TI LTS Linker works.

Then, code as below in ASM files, typically in the '.text' part of the file along with any other existing eabi tags. A handy way to turn off the directive in multiple files is to define a MACRO at the high level of your tool, to conditionally add the tag for export to linkers (such as the TI linker) which may not handle the missing tag in an expected manner. For the ARM Compiler, for instance, add the command line argument: -DADD_TAG_ABI_VFP_ARGS, then modify ASM code as below by adding the conditionally assembled line of code:

    .text
    .eabi_attribute Tag_ABI_align_preserved, 1       << ** this tag happened to be in this threadx source file >>

    .if ADD_TAG_ABI_VFP_ARGS
        .eabi_attribute Tag_ABI_VFP_args, 1
    .endif

Another workaround, as George points out. Is to disable the warning in TI Linker.

Arm-based microcontrollers

Arm-based microcontrollers forum

RM48L952: Link time compatibility between threadx library (built using ARM FuSa Compiler tools 6.16.2) and TI code build using TI ARM tools ti-cfg-arm_20.2.7.LTS