5

Going thru the ARMv8 manual, I have the following questions to help understand the big picture.

  1. Can legacy 32 bit app. (ARMv7 or earlier) run as is on the ARMv8 OS?

  2. If the legacy applications need to be rebuilt for ARMv8 and assuming that I rebuild the application as 32 bit (Aarch32), does this need 32 bit OS underlying support? (It is interesting to know how the addressing mechanism works here.)

Please provide references wherever possible.

PS: I am targeting Linux OS with Aarch64 support (3.7 and later)

artless noise
  • 18,969
  • 5
  • 57
  • 95
MS.
  • 841
  • 1
  • 9
  • 22
  • At least in theory there should not be problems running ARMv7 binaries on ARMv8 as it is downwards compatible (http://www.arm.com/products/processors/armv8-architecture.php). However, things might be slightly different when it comes to a specific GNU/Linux distribution (you did not mention which one we're talking about) as it may or may not have all the libraries against which your 32-bit binary has been linked. –  Mar 17 '14 at 18:18
  • 2
    As owners of iPhone5s and iPad Airs will be able to attest, yes - it's possible. An entire 32-bit user-space is required to make this work, from the dynamic linker and libc upwards. Mixing and matching 32- and 64-bit binaries is not possible in the same process. Running a system with processes of each kind will require more RAM as portions of both 32- and 64-bit libraries will be memory resident. – marko Mar 19 '14 at 23:00
  • Thank you Sami Laine and marko for your comments. Yes this looks possible as there is support COMPAT in the kernel for the Syscall APIs. Thank you for bringing up crucial note on libraries.. :) – MS. Mar 22 '14 at 07:00

2 Answers2

5

Aarch64 platform may run 32bit ARM but this compatibility is optional.

To run AArch32 binaries you need all libraries application would use in 32bit versions. Same as with i686 binaries on x86-64 systems.

Marcin Juszkiewicz
  • 126
  • 3
  • Thank you Marcin. Yes, as mentioned by marko, Aarch32 does need all application and its libraries to be 32 bit versions.. – MS. Apr 15 '14 at 21:00
1

There is also a Linux arm64 CONFIG_COMPAT at: https://github.com/torvalds/linux/blob/v4.17/arch/arm64/Kconfig#L1274 which says:

  This option enables support for a 32-bit EL0 running under a 64-bit
  kernel at EL1. AArch32-specific components such as system calls,
  the user helper functions, VFP support and the ptrace interface are
  handled appropriately by the kernel.

which will likely be required, and an ARM employee mentioned on this thread: https://community.arm.com/processors/f/discussions/5535/running-armv7-binaries-on-armv8 that userland instructions are basically the same with some exceptions:

For something like a Linux application, then yes. ARMv8-A includes AArch32, which provides backwards compatibility with ARMv7-A. There are some limitations, such as the SWP instruction no longer being supported. But these are types of things that applications are unlikely to be using (and were deprecated in ARMv7).

For baremetal, you have all the usual problems of using a binary from one platform on another. So you are going to need to do some degree of porting in most cases.

I then tried it for myself with this QEMU full system setup but my attempt failed: I compiled a C hello world with the armv7 compiler as:

arm-linux-gcc -static hello_world.c

and put the built file into the aarch64 target, but when I tried to run it it failed with:

a.out: line 1: syntax error: unexpected word (expecting ")")

even though /proc/config.gz says that CONFIG_COMPAT is set.

It seems that the Linux kernel is not identifying it as an ELF file but rather falling back to /bin/sh, I get the same error if I do:

sh /mnt/9p/a.out

is trying to use the shell binfmt instead of ELF.

In particular, I know that the Linux kernel can choose between archs from the binfmt signature because qemu-user does so: https://unix.stackexchange.com/questions/41889/how-can-i-chroot-into-a-filesystem-with-a-different-architechture

Community
  • 1
  • 1
Ciro Santilli新疆棉花TRUMP BAN BAD
  • 256,395
  • 72
  • 959
  • 767