I have a libray compiled with armclang, and I wan't to link the library to my project which
compiled with arm-none-eabi-gcc.
But when link it, following error happens:
"Object has vendor-specific contents that must be processed by the 'ARM' toolchain"
It come from some object files, which maybe use some assembler instructions specific
for armclang.
So if it is possible that disassemble the object files with fromelf tool or arm-none-eabi-objdump tools,
generate .S files, and then use the arm-none-eabi-gcc(as) tools to compile them again,
at last link them all.
Hi sword_i
It should be possible, within certain limitations, to link an armclang-built library with gcc-compiled code, if both toolchains conform to the same Application Binary Interface (ABI) and Arm C Language Extensions (ACLE).
See developer.arm.com/.../application-binary-interface-for-the-arm-architecture-the-base-standard-abi-2018q4-documentationand developer.arm.com/.../acle
Which version of arm-none-eabi-gcc, exactly, are you using.With which Arm Compiler 6 was the library generated?For which processor/architecture is your codebase built for?
The same error message is reported incommunity.arm.com/.../compatibility-between-gcc-arm-and-ds-5-compilerwhich explains:"There are other potential incompatibilities between the complication defaults between the compilers - it is sometimes useful to figure this out using the "fromelf" tool, specifically the options --dump_build_attributes and --decode_build_attributes. Any attributes specified which are not the same, or specified in one but not the other, cannot be merged and this is what causes the error you're seeing.
Finding out why those attributes are specified is usually a big clue as to which option you need to pass to each compiler to ensure they build using the same ABI and CPU features."
Hope this helps
Hi Stephen
The arm-none-eabi-gcc is 7.3.1, and the arm compiler used for the library
is 4.1, My board is the Cortex-M4 with hardware fpu.
And seems the problem is related with the object compiled by asm,
readelf --decode_build_attributes xxx_asm.o
tells:
"
** Section #8 '.ARM.attributes' (SHT_ARM_ATTRIBUTES) Size : 68 bytes
'aeabi' file build attributes: 0x000000: 05 43 6f 72 74 65 78 2d 4d 34 00 06 0d 07 4d 09 .Cortex-M4....M. 0x000010: 02 11 01 14 02 17 01 1e 04 22 01 20 02 41 52 4d .........". .ARM 0x000020: 00 . Tag_CPU_name = "Cortex-M4" Tag_CPU_arch = ARM v7E-M (=13) Tag_CPU_arch_profile = The microcontroller profile 'M' (e.g. for Cortex M3) (=77) Tag_THUMB_ISA_use = Thumb2 instructions were permitted (implies Thumb instructions permitted) (=2) Tag_ABI_PCS_GOT_use = Data are imported directly (=1) Tag_ABI_FP_denormal = This code was permitted to require that the sign of a flushed-to-zero number be preserved in the sign of 0 (=2) Tag_ABI_FP_number_model = This code was permitted to use only IEEE 754 format FP numbers (=1) Tag_ABI_optimization_goals = Optimized aggressively for small size, speed and debug illusion sacrificed (=4) Tag_CPU_unaligned_access = The producer was permitted to generate architecture v6-style unaligned data accesses (=1) Tag_compatibility = 2, "ARM"
'ARM' file build attributes: 0x000000: 04 01 0e 01 12 01 ......
seems the "ARM" file build attributes is the problem that arm-none-eabi-gcc can not match.
Now just remove the .ARM.attributes in the xxx_asm.o seem resolve the link problem, but don't know
if there are potential issues.
I don't think it is a good idea to just remove the whole of the .ARM.attributes from your object.
The ".ARM.attributes" section can contain both "public" and "private" attributes.
The public attributes, in the 'aeabi' subsection, describe the build attributes of an object file and its compatibility to a consumer toolchain, as detailed in https://developer.arm.com/docs/ihi0045/g/addenda-to-and-errata-in-the-abi-for-the-arm-architecture-abi-2019q1-documentation
The private attributes, in the 'ARM' subsection here, can be ignored by non-Arm linkers. This is signalled by not setting the Tag_compatibility tag, which means it’s implicitly zero, which means that a linker should be free to ignore any vendor attributes that it doesn’t understand.
Arm only uses the private attributes for collusion between the Arm compiler and Arm linker to get better library selection, and so other non-Arm linkers can ignore it.
In your case, the linker is giving an error, but I suspect the linker may be behaving incorrectly.
Are you able to try a more recent version of arm-none-eabi-gcc ? For example, Version 9-2019-q4-major from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
I hope this helps to resolve the issue. If you need further assistance, please let us know the exact version of the Arm Compiler you are using (from armcc --version, or armclang --version).
Stephen