问题标签 [coff]

我已经问过一个类似的问题，“PE Header requirements”，但我对它的答案并不满意。

我正在用 Java SE 1.6 构建一个汇编器/链接器。我已经阅读了大约 5 个关于 PE/COFF 标头和文件格式的不同文档/规范，但我遇到了一个问题：

我生成的文件无效，Windows 说：“X 不是有效的 Win32 应用程序。” 我不知道可能出了什么问题；我仔细检查了 PE Header 和 PE Optional Header 中的每个条目，一切似乎都是正确的。
我有三个部分：

• code（RVA 0x1000，文件0x400）
• data（RVA 0x2000，文件0x600）
• import（RVA 0x3000，文件0x800）

我的入口点值在0x1000（的开头code），我的图像库是0x400000. 节对齐是0x1000，文件对齐是0x200.

请参阅此问题的修订版以查看整个文件。

所以：我抓取了一个有效的 PE 文件（一个简单的“Hello World”消息框应用程序），并开始使用十六进制编辑器 (HxD) 对其进行修改。我收到了很多不同的错误消息，而不是“X 不是有效的 Win32 应用程序。”：

我知道我的code内容不是“有效”代码，但我已经对其进行了测试：无效代码会导致应用程序崩溃错误。

如果“Hello World”PE 文件中的 import-section 内容无效，它会给我错误“Procedure point cannot be found in [...]”，或“Application has failed to start because [..] dll is未找到。”，或应用程序崩溃。这些错误都非常有用；他们都给了我一些线索，知道出了什么问题。

但是我的 PE 文件出现错误“X 不是有效的 Win32 应用程序。”让我发疯：我的 PE 文件有什么问题？

垃圾箱输出：

如何在 exe 文件中检索 IP 指向开头的点？它总是指向 .text 段的开头吗？

我从 Microsoft Visual Studio 2003 工具输出的目标文件中看到了我认为奇怪的行为。该file实用程序告诉我：

对于汇编程序创建的对象，但对于来自 C 文件的对象，我得到的只是：

使用 Microsoft 的dumpbin实用程序和objdump我从 cygwin 获得的工具，我可以反汇编程序集构建的文件，但是对于 C 构建的文件，我从这两个实用程序都没有得到有用的结果。

我有几个与此差异相关的问题：

1. MSVC2003 编译器生成的目标文件格式是什么？
2. 如何反汇编该目标文件？

我对使用 AT&T 语法进行反汇编特别感兴趣 - 我正在移植一个大型源代码库以使其与 GCC 一起工作，我想将此方法用作一些内联汇编例程的快捷方式项目。

编辑：添加更多信息。

当我dumpbin在其中一个文件上运行时，没有结果：

随着objdump，它给出：

在从程序集构建的文件上，我得到了合理的结果。

再次编辑：添加命令行信息。

汇编文件是使用类似于以下内容的命令行构建的：

ml自行执行时说：

C 文件是使用以下命令构建的：

有一些-Iand-D选项传递给ml和 to cl，但为了简洁起见，我在这里省略了它们。此处描述了这些cl选项。

Microsoft PE/COFF SPEC（v8，第 5.4.4 节）说，当符号具有：

1. IMAGE_SYM_CLASS_EXTERNAL 的存储类
2. 和0的节号（IMAGE_SYM_UNDEFINED）

它是“指示大小”的“值”字段（在符号表中）。

这让我很困惑。特别是，我想知道“表示什么大小？”。

通常， CL(visual C++) 使用IMAGE_SYM_CLASS_EXTERNALandIMAGE_SYM_UNDEFINED来表示 externs。

为什么链接器需要知道或关心符号的大小？它不只需要知道一个名称，它是一个外部，并设置适当的重定位条目吗？这些都不应该取决于大小。现在，诚然，编译器需要知道这一点，但它会从头文件中获取该信息，而不是从目标文件中。

我查看了一些由 CL 编译的简单示例 extern，Value 字段似乎总是为零。所以，它显然没有被用来编码字段的大小。

有谁知道规范指的是什么“尺寸”？他们是否有任何视觉工作室链接器可能使用该字段的场景，或者规范中的宣传只是胡说八道？我有限的大脑无法想到任何这样的场景。

更新：

请注意，它并不（至少不总是）看起来是符号的大小。在我观察到VALUE IS ALWAYS 0的情况下，这就是问题所在。

我正在 MPLAB IDE 中开发代码，我想知道使用编译器生成的 .COFF 或 .HEX 文件对芯片进行编程是否更好。我不确定两者之间有什么区别，我假设他们都将执行相同的工作。

我有一个用 microsoft visual studio 生成的地图文件。它包含一个相对较大的区域，名为 __NULL_IMPORT_DESCRIPTOR。这有什么好处？它与链接的 dll 有关，但我无法弄清楚它的确切目的。

有没有办法从 OMF 16 位目标文件格式转换为 COFF 32 位目标文件格式？

这应该是一个简单的问题：我知道 PE 的 VA = RVA + imagebase，现在我试图在反汇编程序中找到一个字符串，并且恰好位于 .text 部分的 0042720E 处。

镜像库是400000，2720E是RVA，到现在还可以。

但是为什么当我在调试器中加载 exe 时，映射指令的内存是 0140720E ？

0140720E（我在 ram 中看到的）和 0042720E（VA）相差 FE0000，这是为什么呢？我错过了什么吗？

合并兼容的 PE 文件部分有什么缺点？

据我了解，Microsoft 的 Portable Executable 格式的 COFF 符号表用于存储导出、导入和调试符号。但是由于我们已经有一个 .edata、.idata 和 .debug 部分，为什么我们需要另一个这样的结构呢？