Cross-Compile ARM with QEMU

Topic Overview

Build arm64 on x86, Run With QEMU

Cross-compilation targets a different ISA than the host CPU. Docker buildx and GitHub Actions arm64 runners use the same toolchain flow: aarch64-linux-gnu-gcc emits arm64 ELF, qemu-aarch64 translates instructions and forwards syscalls to the host kernel.

bashCopy
Loading…

• as/ld prefixed with the triplet produce arm64 objects on an x86 laptop
• qemu-aarch64 user-mode is not full system emulation; it maps Linux arm64 binaries
• Static qemu-aarch64-static inside containers powers multi-arch pulls

Failures often show up as wrong syscall numbers or linker scripts meant for x86.

For this exercise, you will cross-assemble a small program and run it under QEMU. This task asks you to verify output matches native expectations, because Raspberry Pi OS images and arm64 containers on Docker Hub are built exactly this way when CI lacks bare metal.

Keep the relevant man page, ABI doc, or Rust reference chapter open while you work. When your output disagrees with the reference implementation on the same machine, the mismatch is usually an alignment rule, an off-by-one terminator, or a register slot you misread in GDB. Skim the official documentation for the tool or ABI named in the exercise; the prose changes, but register roles, syscall numbers, and ownership rules stay stable across releases.

Your Task

Cross-development means building a binary on one machine for another, then running it under emulation: aarch64-linux-gnu-gcc -static hello.c -o hello && qemu-aarch64 ./hello. When a build hands you a mystery file, the first 32 bytes of its ELF header tell you everything you need: word size, byte order, file type, target machine and entry point. Write the file-plus-advice tool: decode the header, name the cross compiler that targets it, and say how to run it on the current host.

Input

cCopy
Loading…

ELF header fields (offsets in bytes)

Machines

Native: an x86_64 host runs 64-bit x86-64 and 32-bit Intel 80386 directly. An aarch64 host runs only 64-bit LSB ARM aarch64. Everything else needs qemu.

Output

cCopy
Loading…

• Only executables and shared objects get the "on … host" line. Relocatable files print not runnable: link it into an executable first, core files not runnable: a core dump is loaded by a debugger, and other types (type N in the first line) not runnable: unknown file type.
• An unknown machine prints machine N in the first line and then only no cross toolchain or qemu mapping for machine N.
• host prints host: NAME.
• Errors, checked in this order (N is the number of bytes given):
  • NAME: error: bad hex (odd length or a non-hex digit);
  • NAME: error: truncated header (N bytes) if there are under 4 bytes;
  • NAME: error: not an ELF file (magic aa bb cc dd);
  • the truncated error again if there are under 6 bytes;
  • NAME: error: bad class N, then NAME: error: bad data encoding N;
  • the truncated error again if there are under 28 (32-bit) or 32 (64-bit) bytes.
• Other errors: error: host must be x86_64 or aarch64 and error: bad command: LINE.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Decode multi-byte fields with the file's own byte order, not the host's.
2. Solve it in any language. ARM assembly submissions are only compile-checked.

Hidden tests cover 32-bit ARM, big-endian PowerPC, MIPS and S/390, 32- and 64-bit RISC-V, big-endian AArch64 on an ARM host, core files, unknown types and machines, a Mach-O and a PE file, truncated headers and malformed commands.