Offensive Security Researcher & Quantum Cryptography Analyst

Explaining the Concept of Cross-Compilation

Abdul Wahab Junaid
Explain the concept of cross-compilation.

Every time I build firmware for an STM32 or AVR chip on my Linux laptop or Windows PC, I’m relying on cross-compilation without necessarily thinking about it consciously anymore — but understanding what’s actually happening under the hood took some time to click, and I think it’s one of those concepts that makes a lot of other embedded tooling make sense once you really get it. In this article, I’ll walk through what cross-compilation is, why embedded development depends on it almost universally, and how the whole toolchain fits together.

What Is Cross-Compilation?

Cross-compilation is the process of compiling source code on one type of computer (the host) to produce an executable binary that will run on a different type of computer (the target), where the host and target have different processor architectures, instruction sets, or operating environments. In embedded development, the host is almost always a regular desktop or laptop (x86-64 running Windows, macOS, or Linux), and the target is a microcontroller (ARM Cortex-M, AVR, RISC-V, Xtensa) — architectures that can’t run a full compiler themselves, and often have no operating system at all.

graph LR
    subgraph "Host Machine (x86-64 PC)"
    Src[Source Code - .c/.h files] --> CC[Cross-Compiler - arm-none-eabi-gcc]
    CC --> Bin[Target Binary - .elf/.bin/.hex]
    end
    Bin -->|Flash/Program| MCU[Target Microcontroller - ARM Cortex-M]

Native Compilation vs Cross-Compilation

To appreciate why cross-compilation is necessary, it helps to contrast it with native compilation — the kind you’re doing when you compile a desktop application on your PC to run on that same PC. In native compilation, host and target architecture are identical; the compiler’s output instruction set matches the very machine running the compiler.

AspectNative CompilationCross-Compilation
Host architectureSame as targetDifferent from target
ExampleCompiling a Linux x86-64 app on an x86-64 Linux PCCompiling ARM Cortex-M firmware on an x86-64 PC
Can you run the output directly on the host?YesNo — needs the actual target hardware
Common in embedded dev?Rare (some Linux-based SBCs allow native builds)Standard practice

Why Embedded Systems Require Cross-Compilation

A few concrete reasons this is the standard workflow:

  1. Microcontrollers can’t run compilers. A typical microcontroller might have 32KB–512KB of flash and a few KB to a few hundred KB of RAM — nowhere near enough to host a full compiler toolchain, which itself is a substantial piece of software.
  2. No operating system on many targets. Bare-metal firmware runs directly on hardware with no OS underneath it, so there’s no environment to even launch a compiler process within on the target.
  3. Development speed and tooling. Desktop/laptop PCs are vastly faster at compiling than the target hardware could ever be even if it somehow could run a compiler, and PCs offer full-featured IDEs, debuggers, and version control tooling.
  4. One toolchain, many targets. A single development machine can cross-compile for dozens of different microcontroller families, simply by switching toolchains — impossible if compilation had to happen natively on each target.

The Cross-Compilation Toolchain

A full embedded toolchain is made up of several distinct tools working together, not just “the compiler” in isolation:

graph TD
    Src[Source Files - .c/.cpp/.s] --> Compiler[Compiler - arm-none-eabi-gcc]
    Compiler --> Obj[Object Files - .o]
    Obj --> Linker[Linker - arm-none-eabi-ld]
    LinkScript[Linker Script - .ld] --> Linker
    Linker --> Elf[ELF Executable - .elf]
    Elf --> ObjCopy[objcopy]
    ObjCopy --> Bin[Raw Binary - .bin / .hex]
    Elf --> Debugger[Debugger - GDB + OpenOCD/J-Link]
    Bin --> Flash[Flash Programmer - ST-Link, dfu-util, etc.]

The GNU Naming Convention for Cross-Compilers

Cross-compiler toolchains follow a standardized naming pattern indicating the target architecture:

<arch>-<vendor>-<os>-<abi>-gcc

Examples:
arm-none-eabi-gcc      -> ARM, no specific vendor, no OS (bare-metal), embedded ABI
avr-gcc                 -> AVR (simpler naming, no OS/ABI needed)
xtensa-esp32-elf-gcc    -> Xtensa architecture (ESP32), ELF output
riscv64-unknown-elf-gcc -> RISC-V 64-bit, bare-metal ELF

The eabi (Embedded Application Binary Interface) and elf (Executable and Linkable Format) parts specifically indicate this toolchain targets bare-metal embedded systems with no underlying operating system — as opposed to, say, arm-linux-gnueabihf-gcc, which cross-compiles for ARM Linux systems (like a Raspberry Pi) and does expect an OS underneath.

A Practical Cross-Compilation Example (STM32, Command Line)

# Compile source files into object files, targeting ARM Cortex-M4 with hardware FPU
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard \
    -c main.c -o main.o

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard \
    -c startup_stm32f4.c -o startup.o

# Link into an ELF executable using a linker script describing flash/RAM layout
arm-none-eabi-ld -T STM32F407VG_FLASH.ld main.o startup.o -o firmware.elf

# Convert ELF to raw binary suitable for flashing
arm-none-eabi-objcopy -O binary firmware.elf firmware.bin

# Flash the binary onto real hardware
st-flash write firmware.bin 0x08000000

Notice the -mcpu, -mthumb, -mfpu, and -mfloat-abi flags — these tell the compiler exactly which instruction set variant, thumb mode, and floating-point hardware configuration to generate code for, which is architecture-specific information that simply doesn’t apply (or means something entirely different) when compiling natively for an x86-64 desktop.

Example Linker Script Snippet

MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .text : {
        *(.isr_vector)
        *(.text)
        *(.rodata)
    } > FLASH

    .data : {
        *(.data)
    } > RAM AT> FLASH

    .bss : {
        *(.bss)
    } > RAM
}

This tells the linker exactly where in physical memory the interrupt vector table, code, read-only data, initialized data, and uninitialized (zero-initialized) data should live — critical information the linker has no way of knowing on its own, since it depends entirely on the specific target chip’s memory map.

Cross-Compilation in IDEs (Abstracted Workflow)

Tools like STM32CubeIDE, PlatformIO, Arduino IDE, and ESP-IDF all wrap this exact same underlying toolchain (compiler, linker, objcopy, flashing tool) behind a build-button GUI or a simple CLI command:

# PlatformIO example - cross-compiles and flashes with one command
pio run --target upload

Under the hood, PlatformIO downloads the correct architecture-specific toolchain (e.g., arm-none-eabi-gcc for STM32, xtensa-esp32-elf-gcc for ESP32), invokes it with the correct flags for your specific board, links against the correct linker script, and calls the appropriate flashing tool — all cross-compilation concepts, just automated.

Cross-Compiling for Embedded Linux (A Related but Distinct Case)

For more powerful embedded targets that do run a full operating system — like a Raspberry Pi, BeagleBone, or custom embedded Linux board — cross-compilation still applies, but the toolchain and workflow differ slightly, often involving a full cross-compilation SDK (like those generated by Yocto or Buildroot) that includes not just a compiler but a complete set of target-matched system libraries:

arm-linux-gnueabihf-gcc -o my_app my_app.c
scp my_app pi@raspberrypi.local:/home/pi/

Here, unlike bare-metal STM32/AVR firmware, the output binary expects a Linux kernel and C library (glibc or musl) to be present on the target at runtime, so the cross-toolchain must be built against matching target system headers/libraries to avoid ABI mismatches.

Common Cross-Compilation Pitfalls

Real-World Embedded Development Workflow

graph LR
    A[Write C code on PC] --> B[Cross-compile with arm-none-eabi-gcc]
    B --> C[Link with target-specific linker script]
    C --> D[Generate .bin/.hex]
    D --> E[Flash to target via ST-Link/JTAG/UART bootloader]
    E --> F[Debug live on target via GDB + OpenOCD]
    F -->|Bugs found| A

This edit-compile-flash-debug loop, entirely dependent on cross-compilation, is the daily rhythm of essentially all embedded firmware development, whether you’re working on a $2 AVR chip or a multi-core industrial ARM SoC.

Real-World Applications

Performance and Reliability Considerations

Cross-compilers offer target-specific optimization flags (-O2, -Os for size optimization, -flto for link-time optimization) that matter significantly more in embedded contexts than desktop development, since flash and RAM are genuinely scarce resources. -Os (optimize for size) is frequently preferred over -O2 (optimize for speed) in embedded builds specifically because flash space is often the binding constraint, not raw CPU throughput.

arm-none-eabi-gcc -Os -mcpu=cortex-m4 -mthumb -c main.c -o main.o

Frequently Asked Questions

Can I test cross-compiled code without the actual target hardware? Partially — tools like QEMU can emulate certain target architectures well enough to run and debug logic that doesn’t depend on real peripheral hardware, and unit testing business logic natively on the host (compiled separately, without hardware-specific code) is common practice, but anything touching real peripherals ultimately needs real hardware validation.

Why can’t I just use my regular desktop GCC to compile for a microcontroller? Because standard desktop GCC is built to target your desktop’s own architecture (typically x86-64) and assumes a full operating system underneath the compiled program; it has no knowledge of ARM Cortex-M instruction encoding, doesn’t know your microcontroller’s memory map, and can’t produce a bare-metal-compatible binary without an entirely different, architecture-specific backend and runtime setup.

What’s the difference between a cross-compiler and a cross-assembler? A cross-assembler only translates hand-written assembly source into target machine code; a cross-compiler additionally translates higher-level languages (C, C++) into that target machine code, typically invoking an assembler internally as one step in its own pipeline.

Do I need to write my own linker script for every project? Not usually — most vendor toolchains and IDEs (STM32CubeIDE, PlatformIO, Arduino) provide a correct, working default linker script for supported chips, and you’d only need to write or heavily modify one for custom memory layouts, bootloader/application partitioning, or unusual advanced use cases like placing specific code/data in particular memory regions.

Summary

Cross-compilation is the foundational reason embedded development works the way it does: a powerful desktop or laptop compiles source code into a binary specifically targeted at a completely different, resource-constrained processor architecture, using a dedicated toolchain (compiler, assembler, linker, objcopy, debugger) matched to that target. Understanding the pieces of this toolchain — especially the linker script’s role in describing physical memory layout — demystifies a lot of what otherwise feels like “magic” in embedded build systems, and becomes essential the moment you need to debug a build error, optimize binary size, or configure a new microcontroller target from scratch.

References and Further Reading

Exit mobile version