ld链接器静默崩溃：如何获取详细输出及排查镜像基址问题

问题背景 #

使用mingw64 GCC 12.2.0编译嵌入式项目时，w64devkit发行版的ld 2.39在指定--image-base选项时会无提示崩溃，输出文件被截断为0长度；但更换为mingw-builds或Code::Blocks提供的ld则可正常工作。

疑问1：如何让ld输出更详细信息？ #

可通过以下手段获取更多调试信息：

• 启用verbose输出：在链接选项中添加-v或--verbose，即使崩溃，也可能在标准错误/输出中留下部分链接过程日志
• 开启调试日志：添加--debug选项，ld会输出符号处理、段布局、内存分配等详细执行步骤，有助于定位崩溃前的关键环节
• 用GDB调试ld：在w64devkit环境中执行：

  gdb --args ld %LDOPT% %OBJFILES%
  

  输入run启动链接流程，崩溃后执行bt命令查看调用栈，定位崩溃的具体函数
• 生成Windows崩溃转储：在系统设置中开启「创建转储文件」，ld崩溃后会生成.dmp文件，可通过WinDbg等工具分析内存访问错误细节

疑问2：镜像基址重定义是否存在已知问题？ #

结合测试结果，该问题并非通用的ld 2.39 bug，而是w64devkit特定构建的问题：

• 非页对齐基址的处理bug：你使用的0xD00020等基址并非x86默认页大小（0x1000）的整数倍，同时设置了--section-alignment=0x20，w64devkit的ld可能在计算段偏移时存在内存越界
• 构建差异导致的未定义行为：mingw-builds与w64devkit的ld编译选项、依赖库（如libc）不同，w64devkit的构建可能遗漏了PE格式处理的关键补丁，或引入了编译层面的错误
• binutils已知bug参考：可查看GNU binutils Bugzilla确认是否有针对PE目标、非标准基址的崩溃报告，但你的情况更偏向发行版专属问题

临时解决方案 #

• 直接替换为mingw-builds版本的ld 2.39，已验证可正常工作
• 尝试将--image-base调整为页对齐地址（如0xD01000），验证是否为非页对齐触发的bug
• 若项目兼容，暂时使用Code::Blocks的ld 2.30替代

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