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.

Floating Point Setting Mismatch with FPv4SPD16 and Tag_ABI_VFP_args = 0 or 1

Other Parts Discussed in Thread: TM4C123GH6PM

I am having a somewhat similar problem to "where can I download arm compiler 4.9.0 ?" (second half of discussion) and "Bluetopia Library with Floating Point Support "FPv4SPD16" and a few others I've seen.

I have a project built on CCS v6.0.1.00040, Tiva C (TM4C123) Launchpad, TI-RTOS 2.0.2.36, TI-RTOS' distribution of driverlib.lib (TivaWare 2.1.0.12573c), and a third party proprietary library.


Things were going smoothly until I tried to link in the third party library. Now I get error:
#16004-D file "...\[thirdpartylibrary].a<[thirdpartylibraryfunction].o>" has a Tag_ABI_VFP_args attribute value of "1" that is different than one previously seen ("0"); combining incompatible files [ProjectName] C/C++ Problem

My project is compiled with: --code_state=16 --abi=eabi -me --fp_mode=strict -g --gcc --define=PART_TM4C123GH6PM --define=ccs --define=TIVAWARE --define=ccs="ccs" --display_error_number --issue_remarks --verbose_diagnostics --diag_warning=225 --gen_aux_user_info --write_diagnostics_file --diag_wrap=off --gen_func_subsections=on --fp_reassoc=off -z -m"[my_project].map" --heap_size=0 --stack_size=512 -i"[thirdpartylibrary/directory]" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="[my_project]_linkInfo.xml" --rom_model


The third party library was compiled with settings: -Os -ffunction-sections -fdata-sections -Wall -Wa,-adhlns="$@.lst" -c -fmessage-length=0 -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=vfpv4 -g3 -gdwarf-2

I'm especially confused because even when I remove the standard lib.a and driverlib.lib links (which produces a bunch more errors of course), I still get the "#16004-D" error.  I believe driverlib.lib was compiled as FPv4SPD16, but I'm not 100% sure about the rtsv7M4_T_le_v4SPD16_eabi.lib (lib.a).

Can someone help to point out where my project has a floating point setting mismatch?

  • You can use the command-line executable armofd on the object files and libraries to see what the values of Tag_ABI_VFP_args mean.

    • Tag_ABI_VFP_args == 0 means "FP arguments are passed using the standard AAPCS variant"
    • Tag_ABI_VFP_args == 1 means "FP arguments are passed using the VFP register argument variant of the AAPCS"

    You can tell that rtsv7M4_T_le_v4SPD16_eabi.lib is compiled with TI option --float_support=FPv4SPD16 because of the "v4SPD16" in the name of the library.  You shouldn't need to worry about the rts*.lib/libc.a, the linker will pick between several versions, one of which should be the right one.

    You don't seem to be using the --float_support option when compiling your project.  What happens if you add --float_support=FPv4SPD16 to your options?

  • Actually, you don't seem to be using the --silicon_version=7M4 option either; you should be using that option, and it implies --float_support=FPv4SPD16

  • Thanks for the feedback, Arch.  I agree that my compiler params (--silicon_version or --float_support) don't show up on the console or params list, even though they are set in the GUI as you specified.  After typing them specifically into the 'Set Additional Flags...' window, the --float_support sticks, but the --silicon_version gets removed.  After a clean/build, the project remains the same as before with the VFP_args conflict.

    I used the armofd which you pointed out, and it brought up some differences in the libraries... I've tried to summarize the pertinent information revealed without simply pasting the entire printout.  See attached spreadsheet.  2063.library comparison.xlsx

    In short, the third-party library doesn't specify a Tag_VFP_arch, but the TI libraries do specify Tag_VFP_arch 6 (Some FPv4-SP-D-16 instructions used).

    Is my only option for using this third-party library going to the authors and asking them to recompile it according to these parameters in the spreadsheet?  Are the FP _denormal and _exception requirements in this third-party library something else I need to bring into compatibility?  Is it reasonable to try to recompile the TI libraries instead and preserve efficiency?  

    [On a side note, you might notice that the size of wchar_t is different in this thirdparty lib.  That's another hurdle I'm going to have to get over.]

    Thanks for your time and consideration.

    -snellr

  • snellr said:
     I agree that my compiler params (--silicon_version or --float_support) don't show up on the console or params list, even though they are set in the GUI as you specified.  

    That's strange, and seems like a bug

    snellr said:
    the size of wchar_t is different in this thirdparty lib

    The TI compiler does have a switch to set the size of wchar_t, but to match the GCC object file, you'd have to recompile the RTS library, and I'm not sure that's the easiest path.

    I'm afraid I don't have a great deal of expertise with mixing object files with the GCC ARM compiler, so I'm going to have to ask someone else to take up this thread.

  • snellr said:
    I agree that my compiler params (--silicon_version or --float_support) don't show up on the console or params list, even though they are set in the GUI as you specified.

    I would like to focus on this for now.  Please go back to the project you successfully built before you added the 3rd party library.  Please copy-n-paste directly from the Console view the build for one of the .c files.  

    I presume you are not able to build the 3rd party library, and that the build options you show for it in the first post are exactly how the object files in the library are built..

    Thanks and regards,

    -George

  • After removing the 3rd party library, here is a build output for a sample .c file, with file paths shortened.

    'Building file: ../H_Tasks/Wireless_Mgr.c'
    'Invoking: ARM Compiler'
    "c:/ti/ccsv6/tools/compiler/arm_5.1.7/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me --fp_mode=strict --include_path="c:/ti/ccsv6/tools/compiler/arm_5.1.7/include" --include_path="[path000]" --include_path="[path00]" --include_path="[path0]" --include_path="C:/[path1]" --include_path="C:/[path2]" --include_path="[path3]" --include_path="[path4]" --include_path="[path5]" --include_path="[path6]" --include_path="[path7]" --include_path="[path8]" --include_path="C:/ti/tirtos_tivac_2_00_02_36/products/TivaWare_C_Series-2.1.0.12573c" --include_path="C:/ti/TivaWare_C_Series-2.0.1.11577" -g --gcc --define=PART_TM4C123GH6PM --define=ccs --define=TIVAWARE --define=ccs="ccs" --display_error_number --issue_remarks --verbose_diagnostics --diag_warning=225 --gen_aux_user_info --write_diagnostics_file --diag_wrap=off --gen_func_subsections=on --fp_reassoc=off --preproc_with_compile --preproc_dependency="H_Tasks/Wireless_Mgr.pp" --obj_directory="H_Tasks" --cmd_file="./configPkg/compiler.opt" "../H_Tasks/Wireless_Mgr.c"
    'Finished building: ../H_Tasks/Wireless_Mgr.c'
    ' '

    Maybe the "-mv7M4" is interpreted as -mv=7M4 (silicon_version)?
    -snellr

  • Yes, the following are all equivalent, and mean Cortex-M4

    • -mv7M4
    • -mv=7M4
    • --silicon_version=7M4

  • Here is what I think is occurring.  With the TI ARM compiler, when you use the options ...

    -mv7M4 --float_support=FPv4SPD16

    The object files are marked with the build attribute

    Tag_ABI_VFP_args  1   (FP arguments are passed using the VFP register argument variant of the AAPCS)

    The GCC ARM compiler library build uses the options ...

    -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=vfpv4

    So it should also use the build attribute Tag_ABI_VFP_args and set it to the value 1.  But it doesn't use that attribute at all.  By convention, this means the attribute has the value 0.  

    My guess is the files actually are compatible, but because this attribute does not match, the linker issues the error diagnostic.  

    This all points to a problem with the GCC compiler.  Which GCC compiler is being used?

    Here is a short term workaround I do not recommend for use in your production build ... Suppress the diagnostic by adding --diag_suppress=16004 to the linker build options.

    Thanks and regards,

    -George

  • Hi George,

    The third-party arm library documentation indicates that it was built with the gcc 4.7.2 compiler.

    Suppressing the 16004 error does indeed allow my project to build with this other library.  I am in early stages of testing proper functionality using this stop-gap approach.  When I can confirm proper library operation, I'll update the post.

  • snellr said:
    The third-party arm library documentation indicates that it was built with the gcc 4.7.2 compiler.

    Does it indicate who supplies the compiler?  Is it Linaro, CodeSourcery, Red Hat?  While unlikely, they could have built it themselves from the source.

    Thanks and regards,

    -George

  • CodeSourcery is my educated guess based on filepath hints I find in the library file.

  • Well, then, we are in territory that is new to me.  We do not support the GCC compiler from this forum, except for the Linaro ARM compiler that ships with CCS.  So I can't help you directly.

    My suggestion ... Contact the library vendor to tell them that the object files in the library are not marked with Tag_ABI_VFP_args at all.  They should be marked with that attribute, and it should be the value 1.  While I'm not sure, I suspect the bug needs to be fixed in the assembler.  So the library vendor needs to file a bug against CodeSourcery, or maybe even GNU itself.  I'm sorry, but I don't know.

    Thanks and regards,

    -George

  • Just for further reference material, the library authors indicate that their third-party library is compatible with IAR's toolchain (but apparently not TI's toolchain as we've seen).  

    They did recompile with 

    -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

    which did result in, as I have observed, the Tag_ABI_VFP_args flag being set to 1 in the library.

    However, now this version of the library causes the linking step to fail with the following error:

    fatal error #10232: relocation type "R_ARM_ABS32" in file "[librarypath/thirdpartylibraryname].a<[functionname].o>" at offset 0x00000008 in section ".[sectionname]" with id (66) references symbol "" in discarded section with id (68); references to this symbol from this location are not allowed.

    I know there is a similar post to this problem by someone else a year or two back (http://e2e.ti.com/support/development_tools/compiler/f/343/t/191377.aspx) that had no apparent resolution.  As Arch suggested there, I used armar.exe -xv to extract the objects from the archive library file.  I guess the next step is to attempt to link those into my project directly.  Is there a special means for doing this in CCS?

    Thanks,

    -snellr

  • snellr said:
    However, now this version of the library causes the linking step to fail with the following error:

    The only way to advance this issue is to reproduce it ourselves.  Would you be willing to send a test case to us via private channels?

    snellr said:
    I used armar.exe -xv to extract the objects from the archive library file.  I guess the next step is to attempt to link those into my project directly.  Is there a special means for doing this in CCS?

    I don't expect this to work.  If you want to try anyway ... A linker command file can supply object files to the link. Create yet another linker command file which names all the object files from the 3rd party library.  Add it to the project.

    Thanks and regards,

    -George

  • It's almost like e-mail.  Hover your mouse over my avatar or user name.  A window pops up that includes a link titled Start a Conversation.  Click that to bring up a message compose interface.  That interface includes an icon that looks like paper clip.  Use that to attach the .zip file, or whatever you choose to send.  Only I get to see that message and attachment.

    Thanks and regards,

    -George