如何用GDB跟踪DLL调用？如何查看已加载DLL列表？

我来帮你解决这两个核心问题——先搞定已加载DLL的查看方法，再排查EXE体积反常的原因：

在GDB里有几个直接的命令可以查看所有加载的模块，操作步骤如下：

• 先启动GDB并加载你的程序：gdb your_program.exe
• 运行程序到断点处（或者直接执行run后暂停），然后输入以下命令：
  • info sharedlibrary：这是最常用的命令，会列出所有已加载的共享库（包括Windows DLL），每一项都会清晰显示DLL的完整路径、加载地址等信息。如果程序还没运行，可能只会显示系统核心DLL，建议先跑起来再执行。
  • info dll：针对Windows平台的GDB专门做了优化，输出格式更贴合Windows环境，同样能看到DLL的路径和加载状态。
• 小技巧：如果想快速定位某个特定DLL，可以用管道过滤：info sharedlibrary | grep "your_target_dll"，一秒找到你关心的模块是否被正确加载。

你猜的方向很对，静态链接确实会导致EXE体积暴涨，而且因为代码直接嵌入EXE，自然没法跟踪原本的DLL调用。可以按以下步骤验证和解决：

1. 确认是否真的是静态链接 #

• 用objdump工具分析：在MSYS2终端执行objdump -x your_program.exe | grep "DLL Name"。如果输出里完全没有你预期的自定义DLL名称，基本可以确定是静态链接；如果有，说明是动态链接，但可能加载路径或调试符号有问题。
• 检查Code::Blocks编译配置：打开项目的「Build Options」，看链接器选项里是否加了-static参数，或者是否把静态库（.a文件）而非动态导入库（.dll.a）加入了链接列表。

2. 如果是静态链接导致的问题 #

• 修改编译配置：去掉链接器的-static参数，确保链接的是DLL对应的导入库（通常是.dll.a），同时把编译好的DLL文件放到EXE同一目录，或者Windows能搜索到的路径里（比如System32）。
• 重新编译所有模块：确保EXE和DLL都开启了调试信息——在Code::Blocks的「Compiler Flags」里勾选「Produce debugging symbols」（对应GCC的-g参数），并且两者都用Debug模式编译，这样GDB才能无缝跟踪到DLL的代码。

3. 动态链接但仍无法跟踪的额外排查 #

• 确认调试符号匹配：DLL和EXE必须是同一批次编译的Debug版本，单独生成的符号文件（如果有的话）要和DLL完全对应。
• 手动加载调试符号：如果GDB没自动识别到DLL的符号，可以用add-symbol-file your_dll.dll 0x加载地址命令（加载地址从info sharedlibrary的输出里找），强制加载DLL的调试信息。

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