为何rv64ima-lp64软浮点编译glibc时ld.so会出现浮点指令

核心原因 #

你看到的ld.so反汇编输出中的浮点指令，绝大多数是反汇编误判导致的，并非真实存在的代码内容：

• objdump -D 会把整个二进制文件的所有字节逐字节按指令解码，不会自动区分可执行代码段、数据段、只读常量段的边界。
• RISC-V采用变长指令格式，没有强制的指令对齐要求，也没有硬编码的指令边界标记。当反汇编器扫到存储跳转表、字符串、编译期常量的区域时，连续的字节序列会被自动匹配到指令格式，其中部分字节组合刚好符合浮点指令的编码规则，就会输出不存在的浮点指令。
• 你贴出的示例反汇编内容有明显的解码异常特征：标注为fld的指令仅占2字节长度，而标准双精度浮点加载指令本身是4字节格式，仅有的2字节压缩浮点指令支持的偏移范围远小于示例中的504、304这类大偏移；后续指令流中出现大量无意义的四字节无效值、指令跳转逻辑完全不连贯，都是反汇编器解码偏移跑入数据区的典型表现。

正常配置下，rv64ima-lp64编译的glibc本身不会主动生成任何浮点指令，因为需要兼容无F/D扩展的硬件平台。除此之外还有两类可能引入真实浮点指令的场景：

• 交叉工具链的配置没有实际生效，编译glibc时gcc默认使用了带F/D浮点扩展的march参数
• glibc 2.33的构建流程自动覆盖了编译参数，为了性能优化自动启用了带浮点扩展的架构配置

验证与排查步骤 #

• 仅反汇编真正的可执行代码段，排除数据区的误判：
  执行命令riscv64-unknown-linux-gnu-objdump -d --section=.text ld.so，此时输出只会解码.text段的真实代码，若该输出中不存在浮点指令，即可确认之前的输出全是反汇编误判。
• 检查二进制文件内嵌的架构属性标记：
  执行命令readelf -n ld.so，查看RISC-V架构字段的实际配置，确认是否仅为rv64ima，没有f、d浮点扩展的标记。
• 核对编译时的实际参数：
  执行命令readelf -p .comment ld.so，查看编译流程记录的gcc参数，确认实际传入的-march、-mabi值与配置的rv64ima、lp64一致，没有被自动替换为带浮点扩展的配置。
• 精准筛选真实的非法浮点指令：
  执行命令riscv64-unknown-linux-gnu-objdump -d ld.so | grep -E '\.(fld|fsd|fadd|fmul|fsub)'，对筛选出的结果逐一核对地址位置，确认是否处于合法的代码段偏移范围内，排除数据区的误匹配。

内容的提问来源于stack exchange，提问作者Anaadi Mishra