问题标签 [dumpbin]

我正在使用相同的源重新编译 C++ 二进制文件。操作系统是 Windows Server 2008 R2，编译器是 Microsoft Visual Studio 2005。

之后，我正在运行dumpbin.exe /ALL /DISASM /RAWDATA:NONE并比较输出。反汇编没有区别，但匿名命名空间中的某些名称被破坏的方式有所不同。

例如对于 .cpp 文件中的以下定义：

我可以有以下变化：

仅当我比较新构建的 dll 和另一台机器上的旧 dll 时，才会出现差异。如果我在同一台 PC 上编译这个 dll，我没有这个区别。

所以问题是：这个名字中的十六进制数字部分是什么意思？为什么这个十六进制数字部分在某些情况下是不同的？我如何编译这个项目以使这些名称相同。

当尝试使用vcpkgwith在 Windows 10vs2015中安装caffe2:x64-windows时，我收到一个错误dumpbin.exe：

转储文件 E:\vcpkg\packages\caffe2_x64-windows\debug\lib\Caffe2_CPU.lib 链接：致命错误 LNK1104：无法打开文件 'E:\vcpkg\packages\caffe2_x64-windows\debug\lib\Caffe2_CPU.lib'

我认为问题在于dumpbin.exe进程中使用的版本，它无法打开大 lib 文件，这个大于 2 GB，但在目录中C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin我找到了 amd64_x86 等其他版本的目录，dumpbin但我不知道如何配置vcpkg为使用此版本的dumpbin程序。

解决

我解决了我在vcpkg的解决方案中检查代码的问题，我将所有类型为“VC”/“bin”的路径更改为“VC”/“amd64_x86”，这样我在编译后使用了vcpkg使用的chaintool caffe2 我撤消了我的更改。

我已经使用 cmake 在 Linux 上使用 gcc 编译器构建了一个静态库，现在正在使用 msvc 编译器移植到 Windows。我将 CLion 与默认生成器一起使用，即 NMakefiles x64。我已经设法让我的库构建没有错误，但是当我尝试运行库中的任何代码时，程序就会崩溃。在尝试调试时，我正在使用dumpbin.exe查找 COFF 表中缺少的函数名称。

给了我一长串UNDEF符号。这是摘录

列出的一些符号是我正在尝试构建的库的一部分，而其他符号来自依赖库。所有这一切都让我感到困惑，因为我已经两次和三次检查了包含路径和链接库是否准确 - 此外，如果这些不准确，我们不应该得到编译/链接器错误吗？我最困惑的是那里malloc和free那里的存在。我需要做什么才能将表格中的标签转换为mallocfrom EXTERNALto STATIC？

我试图通过静态分析可执行文件来找到类“Greeter”的“vftable”符号的地址（或从基地址的偏移量）。在 Visual Studio 中通过添加断点和反汇编“Greeter”类的构造函数对其进行动态分析时，我能够找到符号的地址。

但这是它的运行时地址。我需要找到一种方法来计算偏移量，方法是使用“dumpbin”之类的工具或类似的工具。我知道我可以通过使用上面的地址来计算偏移量，但我需要一种方法来自动化它，所以它必须通过一个工具。

我尝试在 exe 上使用“dumpbin”来反汇编它并找到与 Greeter 类相同的指令：

所以，我开始尝试找到对这个符号的引用??_7Greeter@@6B@

我尝试通过以下命令使用“dumpbin”：

我得到以下相关输出：

我也得到了这个输出：

有人知道我将如何找到这个符号的偏移量吗？我需要使用特定的“dumpbin”选项来打印反汇编中提到的符号的偏移量吗？

我一直在尝试理解 .obj 文件中的 .debug$S 部分。但这太令人困惑了，几乎没有好的资源可用。我将不胜感激任何帮助！我现在拥有的 .obj 文件是在没有 crt 库的情况下编译的，它只有这个准系统函数：

该程序是使用这些标志编译的cl -Zi main.cpp /link /subsystem? /ENTRY:Entry /NODEFAULTLIB。使用 转储 .obj 文件dumpbin，.debug$S 看起来像这样：

就在我开始我的问题之前，我正在阅读的关于它的文件是这个文件和 github 上 Miscrosoft 的 cvdump的一些文件。

根据这个：

$$SYMBOLS 段的前四个字节用作签名，以指定 $$SYMBOLS 段中包含的符号和类型 OMF 的版本。(...) 如果签名是 0x00000001，则符号和类型 OMF 已被编写为符合 Microsoft CodeView 调试器的 4.0 版规范。签名的所有其他值都被保留。

前四个字节应该是 1，或者，如果不是，则保留这些值；所以我想尝试发现签名上的值“4”的含义是没有帮助的。

那么，签名之后的所有内容都应该是 CodeView 的东西，对吧？

我问这个是因为我不明白为什么它以“F1”开头。据我所知，一般的符号记录结构格式是这样的：

如果是 CodeView，则意味着“F1”是记录的长度，接下来的两个字节，也就是零，是记录索引。但事实证明，没有记录索引 0！我想前 12 个字节只是签名，因为我编译了另一个包含更多代码的程序，而前 12 个字节是相同的！前 12 个字节也是签名的一部分吗？

这一切意味着什么？

Ì 运行命令dumpbin /headers static_lib.lib并看到这部分：

我想检查这是否是一个具有x64架构的库。然后我看到了这条线COMDAT; sym= x86CPUInfo。这条线是什么意思？