Conflicting CPU architectures 13/0 by linker

Asked by Paul

I try to covert bin file by objcopy by the following command line

arm-none-eabi-objcopy.exe" -B arm -I binary -O elf32-littlearm --rename-section .data=.tables,contents,alloc,load,readonly,data test.bin test.bin.o

However, I got the following error during linking

c:/program files (x86)/atmel/atmel toolchain/arm gcc/native/4.8.1429/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld.exe(0,0): error: C:\temp\FREERTOS_SAM_EXAMPLE3\src\test.bin.o: Conflicting CPU architectures 13/0

Seems like arm attribute information isn't inserted into object file.

arm-none-eabi-readelf.exe" test.bin.o -a
ELF Header:
  Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class: ELF32
  Data: 2's complement, little endian
  Version: 1 (current)
  OS/ABI: ARM
  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: 164 (bytes into file)
  Flags: 0x0
  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: 5
  Section header string table index: 2

Section Headers:
  [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
  [ 0] NULL 00000000 000000 000000 00 0 0 0
  [ 1] .tables PROGBITS 00000000 000034 00004c 00 A 0 0 1
  [ 2] .shstrtab STRTAB 00000000 000080 000023 00 0 0 1
  [ 3] .symtab SYMTAB 00000000 00016c 000050 10 4 2 4
  [ 4] .strtab STRTAB 00000000 0001bc 000043 00 0 0 1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There are no relocations in this file.

There are no unwind sections in this file.

Symbol table '.symtab' contains 5 entries:
   Num: Value Size Type Bind Vis Ndx Name
     0: 00000000 0 NOTYPE LOCAL DEFAULT UND
     1: 00000000 0 SECTION LOCAL DEFAULT 1
     2: 00000000 0 NOTYPE GLOBAL DEFAULT 1 _binary_test_bin_start
     3: 0000004c 0 NOTYPE GLOBAL DEFAULT 1 _binary_test_bin_end
     4: 0000004c 0 NOTYPE GLOBAL DEFAULT ABS _binary_test_bin_size

No version information found in this file.

 How do I solve this problem?

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Terry Guo (terry.guo) said :
#1

There are two things here:

1) Is there an .ARM.attribute section in your input test.bin file? If no, then the output test.bin.o has no way to get this section. Without this section, you will face such arch conflict issue. You can use command "arm-none-eabi-readelf -A test.bin" or "arm-none-eabi-readelf -t test.bin" to check.

2) Sometimes we intend to remove the .ARM.attribute section from object file. Then such object file can be freely linked with any other object files. The user has to ensure that two object files are compatible. This is a new feature we are trying to add to linker.

Revision history for this message
Paul (blancyang) said :
#2

There is no .ARM.attribute section in test.bin file. This file could be any type of binary data, like jpeg. Is it possible to add .ARM.attribute section into object file?

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#3

Hi Paul,

I think this is a typical case where the feature we are adding to the linker will be useful. In your case you know there won't be any compatibility problem as the file only some non code binary data.

Revision history for this message
Terry Guo (terry.guo) said :
#4

You can add .ARM.attribute section to your object file. But there is no way to change the section type of this section to expected type. So the added section eventually is useless for linker. Just like what Thomas said, the new feature we are working on can help you. We hope the feature will be in next release.

Revision history for this message
Thomas Kindler (mail-ubuntu) said :
#5

Hi!

I'm running into the same problem here..

@Thomas: What exactly is that new feature? Is it ready yet? How do I use it?

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#6

Actually if you are sure the code doesn't use any float, the solution is to remove the ARM attribute section and then the linker should link without problem. Note that there was a bug in ld which prevented this from working but I believe this should be fixed in our 4.9 release. My colleague Terry will be able to confirm that.

The solution I am working on is to be able to compile a file so that the resulting object file can be linked into both a softfloat project or a hardfloat project. This requires that the file was compiled with a special switch initially so not suitable for you use case. Currently support for it should land in binutils soon but the GCC part is still under development.

Best regards.

Revision history for this message
Terry Guo (terry.guo) said :
#7

When you make sure your objects can be linked together, then just like what Thomas said, removing the attribute section from objects enables you to link them (no need to remove all of them). Here is my patch to implement this feature:
https://sourceware.org/ml/binutils/2014-09/msg00225.html.

Revision history for this message
Thomas Kindler (mail-ubuntu) said :
#8

Cool! I'd like to try it.. will it be in the Q4 release?
Or could you provide a test version in your PPA?

Revision history for this message
Terry Guo (terry.guo) said :
#9

It will be in Q4 release. So far we don't provide test version in PPA.

Can you help with this problem?

Provide an answer of your own, or ask Paul for more information if necessary.

To post a message you must log in.