不能直接混合链接，除非严格对齐abi、指令集扩展和运行时模型；clang与gcc在浮点abi、内建函数、运行时库（compiler-rt vs libgcc）、启动代码及调试信息等方面存在本质差异，混链易致链接失败或静默崩溃。
不能直接混合链接，除非严格对齐 ABI、指令集扩展和运行时模型。
ABI 和调用约定不一致会立即报错
LLVM（Clang）默认使用 lp64d 或 ilp32d ABI（取决于浮点配置），而 GCC 工具链（如 riscv64-unknown-elf-gcc）可能默认启用 lp64（无双精度浮点支持）或 lp64f。一旦目标文件中函数调用传参方式（如浮点参数是否走 fa0-fa7）、栈帧布局、寄存器保存规则不一致，链接器会在 undefined reference to `__float128_add' 或类似符号上失败，甚至静默生成崩溃代码。
- 检查方式：用
readelf -A查看两个.o文件的Tag_ABI_VFP_args和Tag_ABI_FP_rounding属性 - 强制统一：Clang 加
-mabi=lp64d，GCC 加-mabi=lp64d；两者都必须匹配-march（如rv64gc） - 常见陷阱：Clang 默认启用
zicsr和zifencei指令，而旧版 GCC 可能未导出对应内建函数，导致csrrw类内联展开失败
运行时启动代码和库不兼容
Clang 生成的目标文件默认依赖 compiler-rt 的 __aeabi_* 或 __mulsi3 等软整数运算符号，而 GCC 链接时默认找 libgcc 提供的同名符号。二者实现不互通，且符号签名（如参数传递方式）可能不同。
- 解决路径一：全部用 Clang 编译，链接时显式指定
-rtlib=compiler-rt并禁用-nodefaultlibs后手动拉入libclang_rt.builtins-riscv64.a - 解决路径二：全部用 GCC 编译，Clang 输出改用
-fgnuc-version=4.2.1+-nostdlib+ 手动提供 GCC 风格启动代码（_start、__libc_init_array） - 绝对避免：让 Clang 编译的裸机代码和 GCC 编译的 Linux 用户态代码混链——系统调用接口、栈保护机制（
__stack_chk_fail）完全不重叠
LLVM IR 层面可桥接，但需放弃直接 .o 混链
如果必须跨工具链协作，唯一可靠路径是退到 LLVM IR（bitcode）层：用 Clang 以 -c -emit-llvm 生成 .bc，再用 llc 降为 RISC-V 汇编（.s），最后用 GCC 的 riscv64-unknown-elf-gcc -x assembler 统一汇编链接。这样绕开了目标文件格式（ELF section 属性、重定位类型）差异。
- 注意：
llc输出的汇编默认含.option rvc，若 GCC 工具链不支持压缩指令，需加-mno-compress参数 - 调试信息会丢失：DWARF 生成逻辑在 Clang 和 GCC 中不兼容，
gdb无法跨工具链单步 Clang 生成的 IR 降级代码 - 性能代价：IR 降级跳过了 GCC 后端的部分微架构调度优化（如
cortex-a55风格的发射宽度模拟）
真正棘手的不是链接器报错，而是链接成功后在硬件上跑飞——比如 CSR 访问顺序、中断返回地址对齐、或向量寄存器 v0-v7 的保存策略被一方忽略。混合链接本质上是在赌两套工具链对 RISC-V 规范的解释完全一致，而现实里连 zihpm 计数器的读写语义都有细微分歧。
