dSYM ファイル内に含まれる mach-o ファイル用の単純なパーサーを作成しようとしています。16 進数エディター (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_TYPE_ARM である CPU タイプです。
0000000B は、CPU_SUBTYPE_ARM_V7S である CPU サブタイプです。
0000000A は MH_DSYM であるファイルタイプです
00000007 はロード コマンドの数です。
00000D3C は、ロード コマンドが占有するバイト数です。
00000000 はフラグです (フラグなし)
0000001B は、この LC に UUID が含まれていることを示すロード コマンド LC_UUID です。
00000018 0x18 であるロード コマンドのサイズ = 24 バイト (コマンド [4 バイト] + サイズ [4 バイト] + UUID [16 バイト])
ここが奇妙になり、私の質問が来るところです。
情報はリトル エンディアンであるため、UUID (次の 16 バイト) を次のように「後方」に再配置する必要があると考えました: 9B3EAC06-3C1288AB-933B60E8-20F34EA0。ただし、dwarfdumpUUID ( dwarfdump --uuid TestApp.app.dSYM/) を取得するために使用すると、次のようになります。
UUID: A04EF320-E860-3B93-AB88-123C06AC3E9B (armv7s) TestApp.app.dSYM/Contents/Resources/DWARF/TestApp
なぜこれはビッグエンディアン順なのですか? dwarfdumpHex Fiend のバイトと同じ順序で表示されるのはなぜですか?
私は何が欠けていますか？
あなたの助けや提案を前もって感謝します.