What You Will Learn

• The four CPU-level factors that determine which toolchain a target needs
• What big-endian vs little-endian actually changes at the binary level
• Hard-float vs soft-float, and why it matters for performance on real hardware
• What an Application Binary Interface (ABI) is and why mismatches cause silent, hard-to-diagnose bugs
• How to read a GNU target triplet like arm-linux-gnueabihf at a glance

Prerequisites

• The previous two lectures in this series: “What Is a Linux Toolchain?” and “Native vs Cross Compiler Toolchains”

The Four Factors That Define a Target

A cross toolchain isn’t generic — it’s built for one specific combination of CPU-level characteristics. Get any one of these wrong and your binary either fails to run, or worse, runs incorrectly in ways that only show up under specific conditions.

Reading a Target Triplet

All four factors above get compressed into a single identifier used throughout the Linux toolchain ecosystem: the target triplet (sometimes a “quadruplet,” since it often has four dashed fields despite the name). You’ll see this exact naming pattern on cross-compiler binary names, in Buildroot and Yocto configuration, and in countless build error messages.

The “hf” suffix — hard-float — is worth committing to memory: it’s the single most common mistake beginners make when picking a 32-bit ARM cross toolchain. Mixing a hard-float toolchain’s output with a soft-float root filesystem (or vice versa) produces binaries that either fail to run or crash unpredictably, because the calling convention for passing floating-point values disagrees between the two.

Hands-On: Inspecting Triplet Information Directly

Rather than memorizing triplets abstractly, let’s pull this information straight out of real toolchains installed on a standard Ubuntu system, and confirm what a compiled binary actually contains.

# Install a 32-bit ARM hard-float cross toolchain alongside
# the ARM64 one from the previous lecture
$ sudo apt install -y gcc-arm-linux-gnueabihf

# Ask each cross compiler what triplet it identifies as
$ arm-linux-gnueabihf-gcc -dumpmachine
arm-linux-gnueabihf

$ aarch64-linux-gnu-gcc -dumpmachine
aarch64-linux-gnu

# Your native host compiler reports its own triplet too
$ gcc -dumpmachine
x86_64-linux-gnu

Now build one original source file with the 32-bit ARM hard-float toolchain and inspect the resulting binary’s actual float ABI using binutils — this proves the toolchain choice really did encode hard-float support into the output:

$ cat > ep_float_check.c <<'EOF'
#include <stdio.h>

int main(void)
{
    double a = 3.14159;
    double b = 2.71828;
    printf("sum = %f\n", a + b);
    return 0;
}
EOF

$ arm-linux-gnueabihf-gcc -O2 -o ep_float_check ep_float_check.c

$ readelf -A ep_float_check | grep -i "float\|Tag_ABI"
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed

The Tag_ABI_VFP_args: VFP registers line confirms the compiler generated code that passes floating point arguments through the hardware FPU’s VFP register set — exactly what the “hf” in gnueabihf promises. If you rebuilt the same source with the older soft-float gnueabi toolchain, that line would report core integer registers instead, and the two resulting binaries would be incompatible with each other’s calling convention for any function that passes a float or double.

Why This All Matters in Practice

These four factors aren’t academic — they’re exactly what you check first when a cross-compiled binary refuses to run, or runs but produces corrupted output, on real hardware.

• Wrong architecture → binary won’t execute at all (“Exec format error,” as shown in the previous lecture).
• Wrong endianness → binary may appear to start but reads and writes memory-mapped data incorrectly.
• Wrong float ABI → crashes or garbage values specifically in floating-point code paths, often intermittent and confusing to debug.
• Wrong general ABI → linker errors at build time, or crashes at runtime if the mismatch slips past the linker.

Common Mistakes and Troubleshooting

• Downloading a soft-float toolchain for a board with an FPU. The binary will run, but floating-point-heavy code will be needlessly slow — always confirm your target’s FPU situation before picking a toolchain.
• Mixing hard-float and soft-float libraries. Linking a hard-float application against a soft-float shared library (or the reverse) is a classic source of crashes that only appear when a specific floating-point function gets called.
• Assuming “ARM” is specific enough. ARM alone tells you nothing about bitness, endianness, or float ABI — always confirm the full triplet your target needs.
• Not checking a board’s actual endianness default. A handful of architectures (MIPS, some ARM configurations) can run either endianness depending on how the SoC vendor configured it — check your board’s documentation, don’t assume.

Best Practices

• Get your board’s exact CPU model and datasheet before selecting a toolchain — don’t guess architecture details from marketing material.
• Use -dumpmachine on any cross compiler you’re handed to instantly confirm what triplet it targets, rather than trusting a filename or folder name alone.
• When something doesn’t run right, check triplet-level details with readelf -A before assuming the bug is in your application code.
• Standardize on hard-float toolchains for any modern ARM board with an FPU — soft-float is now mostly a legacy or niche choice.

Summary and Key Takeaways

• Architecture, endianness, floating point support, and ABI together define exactly which toolchain a target needs.
• Target triplets like arm-linux-gnueabihf compactly encode all of this, and appear throughout the cross-compilation ecosystem.
• Mismatches in any one of the four factors cause failures ranging from immediate (“Exec format error”) to subtle and intermittent (float ABI mismatches).
• Tools like -dumpmachine and readelf -A let you verify these details directly instead of guessing.

Conclusion

Choosing a toolchain isn’t a single decision — it’s four decisions bundled into one triplet, and every one of them has to match your target hardware exactly. With this lecture, you now have the complete picture this free linux device drivers course needs before we move on to C library choices, where we’ll examine how glibc, musl, and uClibc-ng trade off size, features, and compatibility for embedded root filesystems.

FAQ