选硬浮点（gnueabihf或aarch64-linux-gnu）是绝大多数arm linux场景的默认且正确选择，因其abi兼容性要求严格，软硬浮点二进制互不兼容，且现代linux发行版均基于硬浮点构建。
选硬浮点（gnueabihf 或 aarch64-linux-gnu）是绝大多数 ARM Linux 场景的默认且正确选择，除非你明确要支持无 FPU 的老芯片或裸机环境。
硬浮点 vs 软浮点：ABI 兼容性是硬门槛
软浮点（gnueabi）和硬浮点（gnueabihf）不是“性能开关”，而是两套互不兼容的二进制接口。它们在函数调用时传递浮点参数的方式完全不同：
-
gnueabi：所有浮点数都通过通用寄存器（r0-r3）或栈传递，不使用 FPU 寄存器；所有浮点运算由软件库模拟 -
gnueabihf：浮点参数直接通过 VFP/NEON 寄存器（s0-s31、d0-d15）传递，指令直接发给硬件 FPU 执行
这意味着：用 gnueabihf 编译的可执行文件，在 gnueabi 系统上运行会立即触发 Illegal instruction；反之，gnueabi 二进制在 gnueabihf 系统上虽能启动，但链接时大概率报 undefined reference to `__aeabi_fadd' 这类符号错误——因为 libc 和 libgcc 的浮点辅助函数实现完全不匹配。
LLVM 工具链里怎么指定浮点 ABI
LLVM（Clang）不靠工具链前缀自动推断浮点行为，必须显式传参。关键选项只有两个：
-
-mfloat-abi=hard：启用硬浮点 ABI（对应gnueabihf），要求目标平台有 FPU 支持且系统镜像为armhf或aarch64 -
-mfloat-abi=softfp：软浮点调用约定（仍用硬件 FPU 运算，但参数走整型寄存器），兼容性略宽，但性能损失约 10–15%，且已基本被弃用
注意：-mfloat-abi=soft 在现代 ARM Linux 上几乎无意义——它强制禁用所有硬件浮点指令，连 Cortex-A72 这种带完整 NEON/VFPv4 的芯片也得纯软件算，毫无必要。LLVM 官方文档也明确标注该模式仅用于极早期无 FPU 的 SoC。
典型 Clang 命令示例：
clang --target=arm-linux-gnueabihf -mfloat-abi=hard -mfpu=vfpv4+neon \ -I$SYSROOT/usr/include -L$SYSROOT/usr/lib \ -o app app.c
为什么你的开发板明明有 FPU，却还报 Illegal instruction
常见原因不是编译错了，而是运行环境不匹配：
- 系统镜像本身是
armel（即gnueabi）而非armhf（gnueabihf）——比如某些老旧 Debian 镜像或定制精简版 rootfs - 交叉工具链的
sysroot指向了gnueabi版本的 libc，但你用了gnueabihf的编译器前缀，导致头文件和库混用 - 目标板内核未启用 VFP/NEON 支持（
CONFIG_VFP=y、CONFIG_NEON=y），或用户态未正确配置浮点寄存器保存/恢复逻辑（尤其在内核模块或中断上下文中）
验证方法：在目标板上运行 cat /proc/cpuinfo | grep -i 'vfp\|neon'，确认有输出；再运行 readelf -A $(which ls) | grep -i float，检查是否含 Tag_ABI_VFP_args: 1（表示硬浮点 ABI）。
裸机或 RTOS 场景下软浮点仍有存在价值
如果你用的是 arm-none-eabi 工具链（如 LLVM-ET），情况不同：
- 默认就是
-mfloat-abi=softfp或soft，因为裸机没有 OS 协助保存/恢复 FPU 寄存器，硬浮点 ABI 在中断或任务切换时极易出错 - 若你确定自己管理了完整的 FPU 寄存器上下文（例如在 FreeRTOS 中启用了
configUSE_TASK_FPU_SUPPORT），才可尝试-mfloat-abi=hard，但需同步修改启动代码和上下文切换汇编 - 对 Cortex-M4/M7 这类带 FPU 的 MCU，
-mfloat-abi=hard+-mfpu=fpv4-d16是性能最优组合，但务必确认你的 RTOS 或启动框架真正支持
一句话收尾：Linux 用户别纠结软浮点，gnueabihf 是事实标准；裸机用户先确认 FPU 上下文管理是否到位，再动 -mfloat-abi，否则默认 softfp 最稳妥。
