1

I have board with an arm920t cpu (AT91RM9200). On the target Linux:

root@test-device:/home/andy # uname -a
Linux test-device 2.6.21.201509.01 #13 Wed Jun 22 11:06:51 EEST 2016 armv4tl unknown

On the my host machine I use virtual machine Ubuntu 18.04 as a system to cross-compile. At the my Ubuntu I have 2 packages for cross-compling:

  1. arm-linux-gnueabi
  2. arm-none-eabi

Try to build simply hello world

include

int main()
{
    printf("Hello world\n");
    return 0;
}

I do it from each of packages

1. supersonic@ubuntu-vBox:~$ arm-linux-gnueabi-gcc -o hello_arm hello.c -static
2. supersonic@ubuntu-vBox:~$ arm-none-eabi-gcc -o hello_arm_none-eabi hello.c --specs=nosys.specs

In both cases I got 2 executables binary readelf and file utils say:

1. (arm-linux-gnueabi)
supersonic@ubuntu-vBox:~$ readelf -h hello_arm
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x101a0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          501788 (bytes into file)
  Flags:                             0x5000200, Version5 EABI, soft-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         30
  Section header string table index: 29
supersonic@ubuntu-vBox:~$ 

supersonic@ubuntu-vBox:~$ file hello_arm
hello_arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=15d06e43de8c8d13d7e0110e311532a9187ca9e5, not stripped

2. (arm-none-eabi)

    supersonic@ubuntu-vBox:~$ readelf -h hello_arm_none-eabi 
    ELF Header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF32
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           ARM
      Version:                           0x1
      Entry point address:               0x8148
      Start of program headers:          52 (bytes into file)
      Start of section headers:          186056 (bytes into file)
      Flags:                             0x5000200, Version5 EABI, soft-float ABI
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         3
      Size of section headers:           40 (bytes)
      Number of section headers:         27
      Section header string table index: 24

    supersonic@ubuntu-vBox:~$ file hello_arm_none-eabi 
    hello_arm_none-eabi: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

Uploaded both files to the target machine, seted permission to execute

root@test-device:/home/andy # chmod +x hello_arm
root@test-device:/home/andy # chmod +x hello_arm_none-eabi

When I try to launch each of this binaries, got following results

  1. (arm-linux-gnueabi)

    root@test-device:/home/andy # ./hello_arm Illegal instruction

  2. (arm-none-eabi)

    root@test-device:/home/andy # ./hello_arm_none-eabi Segmentation fault

On the target machine located old working binary, but developer who made it in curent time not available and he contacts was lost

This is working binary readelf and file utils say about it:

supersonic@ubuntu-vBox:~$ readelf -h /media/share_rw/MTXReader 
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:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0xab1c
  Start of program headers:          52 (bytes into file)
  Start of section headers:          681968 (bytes into file)
  Flags:                             0x2, GNU EABI, <unknown>
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         38
  Section header string table index: 35

supersonic@ubuntu-vBox:~$ file /media/share_rw/MTXReader 
/media/share_rw/MTXReader: ELF 32-bit LSB executable, ARM, version 1 (ARM), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.10, with debug_info, not stripped

Also try build my "hello world" with options
1. supersonic@ubuntu-vBox:~$ arm-linux-gnueabi-gcc -o hello_arm hello.c -static -mcpu=arm920t -march=armv4t
2. supersonic@ubuntu-vBox:~$ arm-none-eabi-gcc -o hello_arm_none-eabi hello.c --specs=nosys.specs -mcpu=arm920t -march=armv4t
But with same results

Any idea why this happened and what to do?

artless noise
  • 21,212
  • 6
  • 68
  • 105
Oleg Oleg
  • 11
  • 1
  • The "none-eabi" is in the compiler name there for a reason. It will not "do wonders and just work". And it will not work on gnu/unix systems, it is designed to work as a compiler for specific cpu / instruction set, it does not include all the startup files relevant for setting and working inside gnu/unix context. The `none-eabi` version probably links a default crt0.s file which probably directly accesses memory addresses whith on a system that managess the memory accesses and permissions will seg fault the program. – KamilCuk Mar 02 '19 at 16:00
  • 2
    Possible duplicate of [What is the difference between arm-linux-gcc and arm-none-linux-gnueabi](https://stackoverflow.com/questions/13797693/what-is-the-difference-between-arm-linux-gcc-and-arm-none-linux-gnueabi) – KamilCuk Mar 02 '19 at 16:04
  • Kamil Cuk, no it's defferent – Oleg Oleg Mar 02 '19 at 16:56
  • Given (1) arm-linux-gnueabi only produces an illegal instruction, you may get further by adding the `-march=arm4tl` compiler option. Also see GCC's [ARM Options](https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html). The segfault from (2) arm-none-eabi will probably be harder to track down. – jww Mar 02 '19 at 17:23
  • option -march not has value arm4tl, just armv4t, as I decribed above. Im trying use -mcpu=arm920t and -march=armv4t, but not got any relults – Oleg Oleg Mar 02 '19 at 17:42
  • can you try with these options -msoft-float -march=armv4t -mtune=arm920t -mcpu=arm920t – Rajnesh Mar 02 '19 at 17:54
  • 1
    Can you use the code in [Select static library with ARM cross compile](https://stackoverflow.com/questions/24616226/how-can-i-select-a-static-library-to-be-linked-while-arm-cross-compiling) to see if you can get that to work with your tool set? Take a look for `ldd` on your target and run that with known working executables to see what libraries are used. You need the same on your development machine. For instance, you may have busybox and not glibc, etc. No one can know if/what duplicate this is as the OPs issue is not apparent. – artless noise Mar 04 '19 at 17:29
  • 1
    NOTE! Your target is saying it is little endian. It is odd, but that is a normal ARM options afair. If the above code doesn't work you need to experiment with `-mcpu` options. Also try different endian changes. The code above should not have floating point issue enter into the equation. You can gradually add things if you get something working to diagnose the issue. Most likely your target libc, OS, etc is not matching your compiler. It is quite complex to get working. Your best bet is to pick up an old version of crosstool-ng to get a compiler with your libc/OS or update them. – artless noise Mar 04 '19 at 17:42
  • 2
    `arm-none-eabi-gcc` is not the correct compiler to use for your situation (NONE means NO OS). It targets an ARM system without an OS. It's library is called [newlib](https://sourceware.org/newlib/) and it requires a different API. Your libc linked with binary might be making Linux syscalls that don't exist with your OS and it uses bad return values. – artless noise Mar 04 '19 at 20:05

0 Answers0