• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 413 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ARM-CGT: Unable to select EABI version

Victor Moreno
Prodigy 10 points
Part Number: ARM-CGT

Hi,

I have some issues with the latest TI ARM-CGT-Clang compiler/linker v3.2.2 LTS. I have some libraries (.a) compiled with a Green Hills Multi compiler (v2018.5.4) , which I am trying to integrate into a new project developed with ARM-CGT-CLANG. However the linker is throwing some errors due to incompatible ABI versions among the object files. The libraries are compiled with the ABI version 3 and the files generated by ARM-CGT-CLANG are ABI version 5.

I'm not able to use any option as -meabi or -mabi to change the ABI version of the new files generated by the ARM-CGT-CLANG. I have even modified the field e_flags in the header of the ELF file to have the ABI version 3 and the linker is not getting the change.

Do you know any work-around to solve the problem? Or any compiler flag which allow me to integrate them?

Best Regards,

Victor

  • 0
    TI__Expert 4680 points

    Hi Victor -- can you elaborate what you mean by "ABI version 3" and perhaps show what options you're building with and what the error messages you're seeing are? 

    While in some cases you can link against other Arm libraries with tiarmclang, we don't recommend that you do that and instead built your project with tiarmclang entirely. 

    Are the Green Hills libraries built in a portable way (i.e. using _AEABI_PORTABILITY_LEVEL)?

    -Alan

  • 0
    Prodigy 10 points

    Hi Alan,

    Unfortunally, the Green Hills libraries are mandatories for our project, thus the need to link them with our code. The libraries are provided by a third party and we do not have information regarding any matter and we can not request any change.

    The following error is displayed by the linker: 'error: ABI version of libFile1.a<InternalObject.o>" (3) is incompatible with "File2.o" (5)'.

    The compiler flags are: -mbig-endian -mcpu=cortex-r5 -marm -std=c99 -g -mno-unaligned-access -fno-function-sections -fno-data-sections -MD -fno-inline-functions

    Best Regards,

    Victor

  • 0 in reply to Victor Moreno
    TI__Guru**** 249175 points

    There are a few different versions recorded in an Arm object file.  This particular one is the version of the ABI.  For details about it, search this page of the Arm EABI specification for EF_ARM_ABIMASK.  Note it appears in the most significant byte of the e_flags field in the file header.  This command is one way to see it ...

    $ tiarmreadelf --file-header executable_file.out | findstr Flags
  Flags:                             0x5000000

    This example, built with tiarmclang, uses ABI version 5.  ABI version 5 is the only one ever supported by TI.  This is the first time I have seen an ABI version other than 5.  I presume version 3 is incompatible in some fundamental way.  Unfortunately, I'm not aware of any way to combine files with these different versions of the ABI.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 10 points

    Hi George,

    As you mentioned, the mask EF_ARM_ABIMASK in the attribute e_flags of the ELF header provides the ABI version. As a workaround we modified this value into our object file compiled by tiarmclang (we changed from 0x05 to 0x03).

    We assumed that should solve the problem of ABI version compatibilities. However, the tiarmclang linker does not care of this value, as it seems to get the value from other attribute and displays the same error as in my previous post.

    Best Regards,

    Victor.

  • 0 in reply to Victor Moreno
    TI__Guru**** 249175 points
    Victor Moreno said:
    we modified this value into our object file compiled by tiarmclang (we changed from 0x05 to 0x03).

    Please don't do that.  That puts the object file into an untested state, and makes it impossible for us to support you.

    Thanks and regards,

    -George