• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 4718 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SYS/BIOS examples for Cortex-A15 generate linker errors in CCS 6.2.0 due to the FPU related flags passed to the GCC linker

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: 66AK2H14, 66AK2H12, SYSBIOS, AM5728

Using CCS 6.1.3.00033 SYS/BIOS had created  projects for the Cortex-A15 in a 66AK2H14 using SYS/BIOS 6.45.1.29 and GNU compiler v4.9.3.

When changed to using CCS 6.2.0.00048 the GCC linker was reporting errors about incompatible object files due to differences in the use of VFP register arguments. The problem can be shown with the unmodified semihost_66AK2H12_CortexA example from SYS/BIOS 6.45.1.29. With CCS 6.1.3 a successful link:

'Building target: semihost_66AK2H12_CortexA.out'
'Invoking: GNU Linker'
"C:/ti_ccs6_1_3/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -mfloat-abi=hard -g -gdwarf-3 -gstrict-dwarf -Wall -Wl,-Map,"semihost_66AK2H12_CortexA.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_45_01_29/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -o"semihost_66AK2H12_CortexA.out" "./semihost.o" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -lgcc -lm -lrdimon -lc -Wl,--end-group 
'Finished building target: semihost_66AK2H12_CortexA.out'

With CCS 6.2.0 a failed link:

'Building target: semihost_66AK2H12_CortexA.out'
'Invoking: GNU Linker'
"C:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -mcpu=cortex-a15 -marm -mfloat-abi=hard -g -gdwarf-3 -gstrict-dwarf -Wall -Wl,-Map,"semihost_66AK2H12_CortexA.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_45_01_29/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -o"semihost_66AK2H12_CortexA.out" "./semihost.o" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -lgcc -lm -lrdimon -lc -Wl,--end-group 
makefile:144: recipe for target 'semihost_66AK2H12_CortexA.out' failed
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: error: semihost_66AK2H12_CortexA.out uses VFP register arguments, c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(bpabi.o) does not
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(bpabi.o)
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: error: semihost_66AK2H12_CortexA.out uses VFP register arguments, c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(_divdi3.o) does not
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(_divdi3.o)
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: error: semihost_66AK2H12_CortexA.out uses VFP register arguments, c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(_udivdi3.o) does not
c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3\libgcc.a(_udivdi3.o)
collect2.exe: error: ld returned 1 exit status
gmake: *** [semihost_66AK2H12_CortexA.out] Error 1

There is a difference in the flags passed to the GCC linker between the two CCS versions.

CCS 6.1.3 passes:

-mfloat-abi=hard 

CCS 6.2.0 passes:

-mcpu=cortex-a15 -marm -mfloat-abi=hard

I guess this change in behavior is a result of the CCS 6.2.0 bug fix for SDSCM00052763.

  • 0
    Guru 92251 points

    Chester Gillon said:
    There is a difference in the flags passed to the GCC linker between the two CCS versions

    The difference in the flags passed to the GCC linker are impacting the GCC multi-lib selection.

    The following multi-libs libraries are available in the gcc-arm-none-eabi-4_9-2015q3 installation:

    C:\ti_ccs6_2_0\ccsv6\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin>arm-none-eabi-gcc.exe --print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-ar/thumb;@mthumb@march=armv7
cortex-m7;@mthumb@mcpu=cortex-m7
armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16
armv7-ar/thumb/softfp;@mthumb@march=armv7@mfloat-abi=softfp@mfpu=vfpv3-d16
armv7-ar/thumb/fpu;@mthumb@march=armv7@mfloat-abi=hard@mfpu=vfpv3-d16
cortex-m7/softfp/fpv5-sp-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=softfp@mfpu=fpv5-sp-d16
cortex-m7/softfp/fpv5-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=softfp@mfpu=fpv5-d16
cortex-m7/fpu/fpv5-sp-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=hard@mfpu=fpv5-sp-d16
cortex-m7/fpu/fpv5-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=hard@mfpu=fpv5-d16

    The flags passed by CCS 6.1.3 select the fpu multi-lib version:

    C:\ti_ccs6_2_0\ccsv6\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin>arm-none-eabi-gcc.exe -print-multi-directory -mfloat-abi=hard
fpu

    Whereas the flags passed by CCS 6.2.0 select the soft FP multi-lib version:

    C:\ti_ccs6_2_0\ccsv6\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin>arm-none-eabi-gcc.exe -print-multi-directory -mcpu=cortex-a15 -marm -mfloat-abi=hard
.

    The GCC Run time options set when the SYS/BIOS semihost_66AK2H12_CortexA example is imported are:

    Note the -mfpu option is blank. When -mfpu was set to vfpv4, the recommended value for a Cortex-A15 based upon ARM Cortex-A Processors and GCC Command Lines, then the program successfully linked in CCS 6.2.0:

    'Building target: semihost_66AK2H12_CortexA.out'
'Invoking: GNU Linker'
"C:/ti_ccs6_2_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -mcpu=cortex-a15 -marm -mfloat-abi=hard -mfpu=vfpv4 -g -gdwarf-3 -gstrict-dwarf -Wall -Wl,-Map,"semihost_66AK2H12_CortexA.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_45_01_29/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -o"semihost_66AK2H12_CortexA.out" "./semihost.o" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -lgcc -lm -lrdimon -lc -Wl,--end-group 
'Finished building target: semihost_66AK2H12_CortexA.out'

    However, there is a difference compared to the original project which was created in CCS 6.1.3 in that the addition of -mfpu=vfpv4 has caused the selection of the armv7-ar/thumb/fpu multi-lib library as opposed to the original (ARM mode?) fpu multi-lib library.

    C:\ti_ccs6_2_0\ccsv6\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin>arm-none-eabi-gcc.exe -print-multi-directory -mcpu=cortex-a15 -marm -mfloat-abi=hard -mfpu=vfpv4
armv7-ar/thumb/fpu

    Given that the "Runtime" options passed to the GCC linker affect the multi-lib library which gets used, what is the rationale behind how CCS 6.2.0 decides which options on the "Runtime" project properties get passed to the GCC linker?

  • 0 in reply to Chester Gillon
    TI__Guru**** 169894 points

    Chester,

    As usual, thanks for such detailed report. I can reproduce this issue with the "Clock" Example of SYSBIOS 6.46.00.23 as well and both CCSv6.1.3 and 6.2.0.

    I found out that the only architecture option the linker accepted is the -mfloat-abi, but unfortunately documentation is somewhat scarce for the ARM embedded GCC compiler - therefore CCSv6.1.3 is right here.  

    To double-check this, I edited the auto-generated makefile from CCSv6.2.0 and selectively removed all the architecture options from the linker except the -mfloat-abi and the project built fine from the command line (just issue a gmake from the Debug directory). I then added the -mfpu=vfpv4 (I also tried vfpv3, vfpv3-d16, etc.) but the linker failed again. To triple-check this, the linker .map file shows the hard floating point libraries are being used.

    Therefore this is a bug introduced with CCSv6.2.0, but I can't tell for sure if it was a consequence of the fix to SDSCM00052763. In any case, I filed today the bug number CCDSK-2246.

    I apologize for the inconvenience,

    Rafael

  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    Therefore this is a bug introduced with CCSv6.2.0, but I can't tell for sure if it was a consequence of the fix to SDSCM00052763. In any case, I filed today the bug number CCDSK-2246.

    I tried the Beta CCS 7.0.0.00017 and this problem has been fixed.

    Using the Beta CCS 7.0.0.00017 could successfully link a program for a Cortex-A15 without having to set a value for -mfpu. The linker command line was:

    'Invoking: GNU Linker'
"C:/ti_ccs7_0/ccsv7/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -mtune=cortex-a15 -marm -g -gdwarf-3 -gstrict-dwarf -Wall -mfloat-abi=hard -Wl,-Map,"task_66AK2H12_CortexA.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_46_01_38/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -o"task_66AK2H12_CortexA.out" "./mutex.o" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -lgcc -lm -lrdimon -lc -Wl,--end-group 
'Finished building target: task_66AK2H12_CortexA.out'

  • 0 in reply to Chester Gillon
    TI__Expert 4630 points
    Chester,

    I was building the UART example in CCS7 (release 7.0.0.00043 ) with PDK 1.0.5 for AM5728, and I ran into this issue. Defining -mfpu as vfpv4 did fix this problem for me, but at least in my case this issue was not fixed by the new release of CCS.

    FYI I was compling UART test for A15 using the GCC toolchain.
    In addition, CCS kept trying to use default gcc versions of standard libraries (libm, libnosys, libg, libc etc), and I had to manually add these libraries to get the example to compile. Is this expected behavior?

    Regards,

    Munan Xu
  • 0 in reply to Munan Xu
    Guru 92251 points

    Munan Xu said:
    Defining -mfpu as vfpv4 did fix this problem for me, but at least in my case this issue was not fixed by the new release of CCS.

    OK, you have probably found a new problem. Can you post the complete linker command line with and without defining -mfpu as vfpv4. As this thread is marked as verified best if you create a new thread and reference this one.

    Munan Xu said:
    In addition, CCS kept trying to use default gcc versions of standard libraries (libm, libnosys, libg, libc etc), and I had to manually add these libraries to get the example to compile. Is this expected behavior?

    Can you describe in more detail which libraries you had to add to get the example to compile. Not sure if the problem is with the example or CCS.

    [So far I have not tried to use the examples from  PDK 1.0.5 for AM5728]

  • 0 in reply to Chester Gillon
    TI__Expert 4630 points
    Chester,

    After checking more the compiler flag options more thoroughly, defining -mfloat-abi hard was enough to get the example to compile. This is included in the example, so it should be fine.

    I did figure out the problem with including the libraries: libm, libc, libg, libnosys. In the project description text file, the library search path was defined as -L$(XDCTOOLS)/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu
    The environment variable $(XDCTOOLS) wasn't evaluating to anything and so CCS defaulted to the standard GNU GCC libraries.
    Changing this to -L"C:/ti/pdk_am57xx_1_0_5/packages/gnu... fixed this.

    Regards,

    Munan