剥离 Windows DLL 调试信息？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/188639/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Strip Windows DLL debug info?
提问by DGentry
I normally don't work on Windows development, and am completely unfamiliar with the toolchain and build system. My embedded product includes some Windows DLLs from a third party in its filesystem (which are used by a Windows machine which mounts the filesystem).
我通常不从事 Windows 开发，并且完全不熟悉工具链和构建系统。我的嵌入式产品在其文件系统中包含来自第三方的一些 Windows DLL（由安装文件系统的 Windows 机器使用）。
I have a problem: the most recent release of these DLLs have tripled in size compared to previous builds, and they no longer fit in the filesystem. There have not been many changes in the functionality of the DLLs, so I suspect the developers simply forgot to strip debug symbols in this drop. I will ask them, but getting an answer often takes days due to timezone and language differences.
我有一个问题：与以前的版本相比，这些 DLL 的最新版本的大小增加了两倍，并且它们不再适合文件系统。DLL 的功能没有太多变化，所以我怀疑开发人员只是忘记在这个 drop 中去除调试符号。我会问他们，但由于时区和语言差异，得到答案通常需要几天时间。
Could someone explain, using simple steps for someone unfamiliar with VisualC, how to determine if a DLL still contains debugging information and how to strip it out?
有人可以解释一下，对不熟悉 VisualC 的人使用简单的步骤，如何确定 DLL 是否仍包含调试信息以及如何将其删除？
采纳答案by jeffm
You'll want to get the release versions from the developers, even if it's a pain, because debug versions are by default compiled with code optimization disabled. So even if you somehow stripped out the debug information you would be left with code that's not as efficient as it could be. (Not to mention whatever debug traps and messages might be in there.)
您会希望从开发人员那里获得发布版本，即使这很痛苦，因为调试版本默认是在禁用代码优化的情况下编译的。因此，即使您以某种方式去除了调试信息，您也会留下效率不高的代码。（更不用说那里可能存在的任何调试陷阱和消息。）
As far as determining what kind of DLL you have, you could use the Dependency Walkerto see if your DLL is linked to the debug or release version of the VC runtime library (assuming those libraries are not statically linked.)
至于确定您拥有哪种类型的 DLL，您可以使用Dependency Walker查看您的 DLL 是否链接到 VC 运行时库的调试或发布版本（假设这些库不是静态链接的。）
回答by Greg Hewgill
Generally the debug info itself is built as a separate *.pdbfile (Program DataBase), instead of being appended onto the binary as in unix. If the developers did indeed build a debug version of the library, a more serious problem might be that of dependencies. If a release version of a binary links to MSVCRT.DLL, then the debug build would link to MSVCRTD.DLL(other runtime libraries are similarly named with the D suffix). To find the dependencies for a particular binary, try:
通常，调试信息本身是作为一个单独的*.pdb文件（程序数据库）构建的，而不是像在 unix 中那样附加到二进制文件中。如果开发人员确实构建了该库的调试版本，那么更严重的问题可能是依赖关系。如果二进制文件的发布版本链接到MSVCRT.DLL，则调试版本将链接到MSVCRTD.DLL（其他运行时库的名称类似，带有 D 后缀）。要查找特定二进制文件的依赖项，请尝试：
dumpbin /imports whatever.dll
This will show all the runtime dependencies for the library whatever.dll(note that both library names and symbols from those libraries are listed). If you do not see the list of dependencies you expect, there is probably a problem that can only be fixed by having the original developer rebuild the library in the proper build mode.
这将显示库的所有运行时依赖项whatever.dll（请注意，这些库中的库名称和符号均已列出）。如果您没有看到您期望的依赖项列表，则可能存在一个问题，该问题只能通过让原始开发人员以正确的构建模式重建库来解决。
回答by Chris Becke
Rebase is part of the microsoft toolset. In addition to setting the base address for dlls it can strip any attached debug info into a seperate .dbg file.
Rebase 是微软工具集的一部分。除了为 dll 设置基地址之外，它还可以将任何附加的调试信息剥离到单独的 .dbg 文件中。
rebase -i 0x10000000 -a -x .\ -p
变基 -i 0x10000000 -a -x .\ -p
You should theoretically try and determine if the dll is already building to a unique base address and use that. Alternativly, choose a base address to minimise the chance of collision with any other dlls used by your application so that windows does not have to patch up the dll when loading it. In an age where loaders routinely randomize the load address of modules as a security feature Im not sure that its worth bothering specifically setting the base address any more.
从理论上讲，您应该尝试确定 dll 是否已经构建到唯一的基地址并使用它。或者，选择一个基地址以最大程度地减少与应用程序使用的任何其他 dll 冲突的机会，以便 Windows 在加载 dll 时不必修补它。在加载程序经常随机化模块的加载地址作为安全功能的时代，我不确定是否值得再专门设置基地址。
回答by mox
回答by 0xC0000022L
Ignoring for the moment the other suggestions such as getting a release version, which is valid. The tool the developers would be looking for is actually link.exefrom Visual Studio (or the SDK or WDK).
暂时忽略其他建议，例如获取有效的发布版本。开发人员正在寻找的工具实际上link.exe来自 Visual Studio（或 SDK 或 WDK）。
If they would like you to be able to make use of a debugger together with their code they could create public PDB files for you. The options they'd want to use are:
如果他们希望您能够将调试器与他们的代码一起使用，他们可以为您创建公共 PDB 文件。他们想要使用的选项是：
/PDB:filename
/PDBSTRIPPED:filename
However, I'm afraid that you yourself can't do a lot about it. The PDB files themselves are separate files and debug information does not usually get included in binaries on modern MS compilers(though some RTTI stuff may get included, not to mention the file names and strings for ASSERTand similar macros and "functions" - which is the most likely explanation for the perceived bloat).
不过，恐怕你自己也无能为力。PDB 文件本身是单独的文件，调试信息通常不会包含在现代 MS 编译器的二进制文件中（尽管可能会包含一些 RTTI 内容，更不用说ASSERT类似宏和“函数”的文件名和字符串了——这是最可能的解释是感知到的膨胀）。
Note: binplace.exefrom the WDK provides the same functionality as the above flags, but has a somewhat more convoluted (albeit fitting for the WDK build process) syntax.
注意：binplace.exe来自 WDK 提供与上述标志相同的功能，但有一个更复杂的（虽然适合 WDK 构建过程）语法。
