LP64D 是 RISC-V Linux 用户态必需的 ABI，因 glibc 函数按其约定编写；LP64 仅 float 入浮点寄存器，double 走整数寄存器，混用会导致传参错位、printf 乱码或崩溃；-march 含 d 扩展时必须配 -mabi=lp64d，否则链接失败；Clang 比 GCC 更严格校验 ABI 匹配。
LP64 和 LP64D 的 ABI 差异直接决定浮点行为
选错 ABI 不会当场报错，但会导致 double 类型传参错位、printf("%f", x) 输出乱码、甚至函数调用崩溃。根本原因在于：LP64 仅把 float 放入浮点寄存器（f0-f7），而 double 仍走整数寄存器（a0-a7）；LP64D 则让 double 也进浮点寄存器。两者调用约定不兼容，混用等于让 caller 和 callee 对寄存器用途有不同理解。
riscv64-linux-gnu-gcc 默认用 LP64D，但裸机环境常需手动指定
Linux 用户态工具链（如 riscv64-linux-gnu-gcc）默认启用 -mabi=lp64d，因为 glibc 的 printf、sin 等函数都按 LP64D 约定编写。但裸机或使用 newlib 的场景（如 riscv64-unknown-elf-gcc）可能默认是 LP64，尤其当你没显式加 -mabi 参数时：
- 检查实际生效的 ABI：编译后运行
readelf -A your.elf | grep abi，看输出是否含lp64d - 强制指定更安全：哪怕工具链默认 LP64D，也显式写
-mabi=lp64d，避免依赖隐式行为 - 若你真不需要双精度浮点，且想省寄存器/栈空间，才考虑 LP64；但绝大多数 Linux 应用必须用 LP64D
和 -march 组合时不能瞎配，否则链接器静默失败
-march=rv64imafdc 含 d（双精度浮点扩展），就必须配 -mabi=lp64d；若只配 lp64，虽然编译能过，但链接时 undefined reference to `__extenddfsf2' 这类符号错误会突然冒出来——因为编译器生成了依赖双精度软仿的调用，而 LP64 ABI 下的 libc 或 runtime 没提供对应实现。
- 常见合法组合：
-march=rv64gc+-mabi=lp64g（g 表示 general，含 double）、-march=rv64imac+-mabi=lp64（无 d 扩展，只能用 lp64） - 非法组合：
-march=rv64imafd+-mabi=lp64—— 编译器可能不拦，但链接或运行时崩 - 验证方法：用
riscv64-unknown-elf-gcc -march=xxx -mabi=yyy -dumpmachine看输出是否稳定，若报错或输出空，说明组合被拒绝
Clang 和 GCC 在 ABI 推导逻辑上略有不同
Clang（riscv64-unknown-elf-clang）对 ABI 更严格：若 -march 含 d，它会强制要求 -mabi=lp64d，否则直接报错 error: invalid ABI for the given architecture。GCC 则更“宽容”，容易让你滑向静默错误。所以用 Clang 反而是种保护——它逼你面对 ABI 匹配问题，而不是留到运行时才发现。
真正容易被忽略的是：ABI 不只是影响浮点，还决定 long double 大小、结构体字段对齐规则、甚至栈帧中浮点寄存器保存方式。一旦在内核模块或 bootloader 里混用 ABI，调试器看到的寄存器值和实际执行流就对不上。
