1

我正在尝试为包含在 dSYM 文件中的 mach-o 文件编写一个简单的解析器。当我在十六进制编辑器（TextWrangler 上的 Hex Fiend 或 Hex 转储）上打开文件时。我看到这样的东西。

CEFAEDFE 0C000000 0B000000 0A000000 07000000 3C0D0000 
00000000 1B000000 18000000 A04EF320 E8603B93 AB88123C 
06AC3E9B ...

第一个值CEFAEDFE只是FEEDFACE倒数，即MH_MAGIC数字。实际上，这是MH_CIGMA因为它是倒退的。这让我觉得其余的信息是小端的：首先是最低有效字节。在 的情况下0xFEEDFACE，最低有效字节是0xCE，这是我上面示例中的第一个字节，然后是其余字节。

所以我继续检查其余的整数（4 个字节）。在重新排列它们以使其格式正确后（即 0C000000 变为 0000000C），我们有：

0000000C 是 CPU 类型，即 CPU_TYPE_ARM

0000000B 是 CPU 子类型，即 CPU_SUBTYPE_ARM_V7S

0000000A 是 MH_DSYM 的文件类型

00000007 是加载命令的数量

00000D3C 是加载命令占用的字节数

00000000 是标志（没有标志）

0000001B是加载命令LC_UUID，表示这个LC包含UUID

00000018 加载命令的大小，即 0x18 = 24 字节（命令 [4 字节] + 大小 [4 字节] + UUID [16 字节]）

现在这就是它变得奇怪的地方，也是我的问题所在。

由于信息是小端的，我认为 UUID（以下 16 个字节）应该像这样“向后”重新排列：9B3EAC06-3C1288AB-933B60E8-20F34EA0。但是，当我dwarfdump用来获取 UUID ( dwarfdump --uuid TestApp.app.dSYM/) 时，我得到了这个：

UUID: A04EF320-E860-3B93-AB88-123C06AC3E9B (armv7s) TestApp.app.dSYM/Contents/Resources/DWARF/TestApp

为什么这是大端顺序？为什么它的打印dwarfdump顺序与我在 Hex Fiend 中看到的字节顺序相同？

我错过了什么？

提前感谢您的帮助或建议。

4

1 回答 1

1

UUID 由rfc4122定义为“网络字节顺序”，也称为大端序。

所以，是的，即使在其他小端结构中，您也需要以这种方式读/写它们。

于 2013-05-25T08:07:33.917 回答