Mac OS X ABI Mach-O File Format Reference

---

title : Mac OS X ABI Mach-O File Format Reference

---

Overview

This document describes the structure of the Mach-O (Mach object) file format, which is the standard used to store programs and libraries on disk in the Mac OS X application binary interface (ABI). To understand how the Xcode tools work with Mach-O files, and to perform low-level debugging tasks, you need to understand this information.

本文檔描述了Mach- o (Mach object)文件格式的結構，這是Mac OS X應用程序二進制接口(ABI)中用於在磁盤上存儲程序和庫的標準格式。要理解Xcode工具如何處理Mach-O文件，並執行 low-level 調試任務，您須要理解這些信息。

The Mach-O file format provides both intermediate (during the build process) and final (after linking the final product) storage of machine code and data. It was designed as a flexible replacement for the BSD a.out format, to be used by the compiler and the static linker and to contain statically linked executable code at runtime. Features for dynamic linking were added as the goals of Mac OS X evolved, resulting in a single file format for both statically linked and dynamically linked code.

Mach-O文件格式提供了機器代碼和數據的中間(在構建過程當中)和最終(在連接最終產品以後)存儲。它被設計爲一個靈活的替代BSD a.out輸出格式，由編譯器和靜態連接器使用，並在運行時包含靜態連接的可執行代碼。隨着Mac OS X目標的發展，動態連接的特性也被添加進來，從而爲靜態連接和動態連接代碼提供了一種單一的文件格式。

Basic Structure

A Mach-O file contains three major regions (as shown in Figure 1):

一個Mach-O文件包含三個主要區域(如圖1所示):

• At the beginning of every Mach-O file is a header structure that identifies the file as a Mach-O file. The header also contains other basic file type information, indicates the target architecture, and contains flags specifying options that affect the interpretation of the rest of the file.

  在每一個Mach-O文件的開頭都有一個頭結構，它將文件標識爲一個Mach-O文件。頭文件還包含其餘基本文件類型信息，指示目標體系結構，幷包含指定影響文件其他部分解釋的選項的標誌。

• Directly following the header are a series of variable-size load commands that specify the layout and linkage characteristics of the file. Among other information, the load commands can specify:

  頭文件後面是一系列大小可變的load commands，它們指定文件的佈局和連接特性。在其餘信息中，load commands能夠指定:

  • The initial layout of the file in virtual memory

    文件在虛擬內存中的初始佈局

  • The location of the symbol table (used for dynamic linking)

    符號表的位置(用於動態連接)

  • The initial execution state of the main thread of the program

    程序主線程的初始執行狀態

  • The names of shared libraries that contain definitions for the main executable’s imported symbols

    包含主可執行文件導入符號定義的共享庫的名稱

• Following the load commands, all Mach-O files contain the data of one or more segments. Each segment contains zero or more sections. Each section of a segment contains code or data of some particular type. Each segment defines a region of virtual memory that the dynamic linker maps into the address space of the process. The exact number and layout of segments and sections is specified by the load commands and the file type.

  按照load commands, Mach-O文件都包含一個或多個segment的數據。每一個段包含零個或多個sections。段的每一個section都包含某種特定類型的代碼或數據。每一個segment定義一個虛擬內存區域，動態連接器將該區域映射到進程的地址空間。segment和sections的確切數量和佈局由load commands和文件類型指定。

• In user-level fully linked Mach-O files, the last segment is the link edit segment. This segment contains the tables of link edit information, such as the symbol table, string table, and so forth, used by the dynamic loader to link an executable file or Mach-O bundle to its dependent libraries.

  在用戶級徹底連接的Mach-O文件中，最後一個段是連接編輯段。此段包含連接編輯信息的表，如符號表、字符串表等，動態加載程序使用這些表將可執行文件或Mach-O包連接到其依賴庫。

  Figure 1 Mach-O file format basic structure

Various tables within a Mach-O file refer to sections by number. Section numbering begins at 1 (not 0) and continues across segment boundaries. Thus, the first segment in a file may contain sections 1 and 2 and the second segment may contain sections 3 and 4.

Mach-O文件中的各類表都是按編號引用節的。節編號從1(不是0)開始，並跨越段邊界。所以，文件中的第一個段能夠包含第1節和第2節，第二個段能夠包含第3節和第4節。

When using the Stabs debugging format, the symbol table also holds debugging information. When using DWARF, debugging information is stored in the image’s corresponding dSYM file, specified by the uuid_command (page 20) structure

當使用Stabs調試格式時，符號表還包含調試信息。使用DWARF時，調試信息存儲在image對應的dSYM文件中，該文件由uuid_command 結構指定

Header Structure and Load Commands

A Mach-O file contains code and data for one architecture. The header structure of a Mach-O file specifies the target architecture, which allows the kernel to ensure that, for example, code intended for PowerPC-based Macintosh computers is not executed on Intel-based Macintosh computers.

一個Mach-O文件包含一個架構的代碼和數據。Mach-O文件的頭結構指定了目標體系結構，這容許內核確保，例如，針對基於powerpc的Macintosh計算機的代碼不會在基於intel的Macintosh計算機上執行。

You can group multiple Mach-O files (one for each architecture you want to support) in one binary using the format described in 「Universal Binaries and 32-bit/64-bit PowerPC Binaries」 (page 55).

您可使用「Universal Binaries and 32-bit/64-bit PowerPC Binaries」中描述的格式將多個Mach-O文件(每一個體繫結構一個)分組到一個二進制文件中。

Note: Binaries that contain object files for more than one architecture are not Mach-O files. They archive one or more Mach-O files.

注意:包含多個體繫結構的目標文件的二進制文件不是Mach-O文件。他們存檔一個或多個Mach-O文件。

Segments and sections are normally accessed by name. Segments, by convention, are named using all uppercase letters preceded by two underscores (for example, _TEXT); sections should be named using all lowercase letters preceded by two underscores (for example, __text). This naming convention is standard, although not required for the tools to operate correctly.

Segments和sections一般按名稱訪問。按照慣例，Segments的命名使用全部大寫字母加上兩個下劃線(例如，__ TEXT); sections的命名應該使用全部小寫字母加上兩個下劃線(例如，__ text)。這只是一個規範的命名約定，不強制要求必須這樣作

Segments

A segment defines a range of bytes in a Mach-O file and the addresses and memory protection attributes at which those bytes are mapped into virtual memory when the dynamic linker loads the application. As such, segments are always virtual memory page aligned. A segment contains zero or more sections.

segment在Mach-O文件中定義一個字節範圍，以及地址和內存保護屬性，當動態連接器加載應用程序時，這些字節被映射到虛擬內存中。所以，segments始終是虛擬內存頁面對齊的。一個segment包含零個或多個sections。

Segments that require more memory at runtime than they do at build time can specify a larger in-memory size than they actually have on disk. For example, the __PAGEZERO segment generated by the linker for PowerPC executable files has a virtual memory size of one page but an on-disk size of 0.

Because __PAGEZERO contains no data, there is no need for it to occupy any space in the executable file.

運行時比構建時須要更多內存的段能夠指定比它們在磁盤上實際擁有的更大的內存大小。例如，連接器爲PowerPC可執行文件生成的__ PAGEZERO段的虛擬內存大小爲一頁，而磁盤大小爲0。因爲__ PAGEZERO不包含數據，所以不須要佔用可執行文件中的任何空間。

Note: Sections that are to be filled with zeros must always be placed at the end of the segment. Otherwise, the standard tools will not be able to successfully manipulate the Mach-O file.

注意:要用零填充的部分必須始終放在段的末尾。不然，標準工具將沒法成功地操做Mach-O文件。

For compactness, an intermediate object file contains only one segment. This segment has no name; it contains all the sections destined ultimately for different segments in the final object file. The data structure that defines a section (page 23) contains the name of the segment the section is intended for, and the static linker places each section in the final object file accordingly.

爲了緊湊性，中間對象文件只包含一個segment。這個segment沒有名字;它包含爲最終目標文件中的不一樣segment指定的全部sections。定義section的數據結構(第23頁)包含節的目標段的名稱，靜態連接器將每一個節相應地放在最終目標文件中。

For best performance, segments should be aligned on virtual memory page boundaries—4096 bytes for PowerPC and x86 processors. To calculate the size of a segment, add up the size of each section, then round up the sum to the next virtual memory page boundary (4096 bytes, or 4 kilobytes). Using this algorithm, the minimum size of a segment is 4 kilobytes, and thereafter it is sized at 4 kilobyte increments.

爲了得到最佳性能，段應該對齊到虛擬內存頁邊界上—PowerPC和x86處理器的4096字節。要計算段的大小，請將每一個段的大小相加，而後將總和四捨五入到下一個虛擬內存頁邊界(4096字節，或4 kb)。使用這種算法，一個段的最小大小是4 kb，而後以4 kb的增量進行調整。

The header and load commands are considered part of the first segment of the file for paging purposes. In an executable file, this generally means that the headers and load commands live at the start of the __ TEXT segment because that is the first segment that contains data. The __PAGEZERO segment contains no data on disk, so it’s ignored for this purpose.

出於分頁的目的，header和load commands被認爲是文件第一segment的一部分。在一個可執行文件中，這一般意味着headers和load commands位於__ TEXT segment的開頭，由於這是包含數據的第一個segment。因爲__PAGEZERO segment沒有包含任何數據，所以忽略了它。

These are the segments the standard Mac OS X development tools (contained in the Xcode Tools CD) may include in a Mac OS X executable:

如下是標準Mac OS X開發工具(包含在Xcode tools CD中)可能包含在Mac OS X可執行文件中的部分:

• The static linker creates a __ PAGEZERO segment as the first segment of an executable file. This segment is located at virtual memory location 0 and has no protection rights assigned, the combination of which causes accesses to NULL, a common C programming error, to immediately crash. The __ PAGEZERO segment is the size of one full VM page for the current architecture (for Intel-based and PowerPC-based Macintosh computers, this is 4096 bytes or 0x1000 in hexadecimal). Because there is no data in the __PAGEZERO segment, it occupies no space in the file (the file size in the segment command is 0).

  靜態連接器建立一個__PAGEZERO segment 做爲可執行文件的第一個segment。這個segment位於虛擬內存位置0，沒有分配任何保護權限，二者的組合會致使對NULL的訪問當即崩潰，這是一個常見的C編程錯誤。對於當前的體系結構(對於基於intel和基於powerpc的Macintosh計算機，這是4096字節，或者十六進制是0x1000)， _ PAGEZEROsegment的大小至關於一個完整的VM頁面。由於在PAGEZERO段中沒有數據，因此它在文件中不佔空間(segment命令中的文件大小爲0)。

• The __ TEXT segment contains executable code and other read-only data. To allow the kernel to map it directly from the executable into sharable memory, the static linker sets this segment’s virtual memory permissions to disallow writing. When the segment is mapped into memory, it can be shared among all processes interested in its contents. (This is primarily used with frameworks, bundles, and shared libraries, but it is possible to run multiple copies of the same executable in Mac OS X, and this applies in that case as well.) The read-only attribute also means that the pages that make up the __ TEXT segment never need to be written back to disk. When the kernel needs to free up physical memory, it can simply discard one or more __TEXT pages and re-read them from disk when they are next needed.

  TEXT segment包含可執行代碼和其餘只讀數據。爲了容許內核將它直接從可執行文件映射到可共享內存，靜態連接器將這個段的虛擬內存權限設置爲不容許寫入。當段被映射到內存中時，它能夠在對其內容感興趣的全部進程之間共享。(這主要用於框架、捆綁包和共享庫，但也能夠在Mac OS X中運行同一可執行文件的多個副本，在這種狀況下也是適用的。)只讀屬性還意味着組成TEXT段的頁面永遠不須要寫回磁盤。當內核須要釋放物理內存時，它能夠簡單地丟棄一個或多個TEXT頁面，而後在下次須要時從磁盤從新讀取它們。

• The __ DATA segment contains writable data. The static linker sets the virtual memory permissions of this segment to allow both reading and writing. Because it is writable, the __ DATA segment of a framework or other shared library is logically copied for each process linking with the library. When memory pages such as those making up the __DATA segment are readable and writable, the kernel marks them copy-on-write; therefore when a process writes to one of these pages, that process receives its own private copy of the page.

  DATA段包含可寫數據。靜態連接器設置此段的虛擬內存權限爲容許讀寫。由於它是可寫的，因此framework或其餘共享庫的DATA segment在邏輯上被複制到與庫連接的每一個進程。當組成DATA段的內存頁可讀可寫時，內核將它們標記爲copy-on-write; 所以，當一個進程寫到其中一個頁面時，該進程將收到該頁面的私有副本。

• The __OBJC segment contains data used by the Objective-C language runtime support library.

  __OBJC段包含OC運行時支持庫使用的數據。

• The __IMPORT segment contains symbol stubs and non-lazy pointers to symbols not defined in

  the executable. This segment is generated only for executables targeted for the IA-32 architecture.

  __IMPORT段含符號存根和指向可執行文件中未定義的符號的非懶加載指針。此段只在IA-32架構下的可執行文件中生成

• The __LINKEDIT segment contains raw data used by the dynamic linker, such as symbol, string, and relocation table entries.

  __LINKEDIT段包含動態連接器使用的原始數據，例如符號、字符串和重定位表條目。

Sections

The __ TEXT and __ DATA segments may contain a number of standard sections, listed in Table 1, Table 2 (page 11), and Table 3 (page 11). The __OBJC segment contains a number of sections that are private to the Objective-C compiler. Note that the static linker and file analysis tools use the section type and attributes (instead of the section name) to determine how they should treat the section. The section name, type and attributes are explained further in the description of the section (page 23) data type.

TEXT和DATA segments能夠包含許多標準sections，如表一、表2和表3中列出。__OBJC段包含許多對Objective-C編譯器私有的部分。注意，靜態連接器和文件分析工具使用section類型和屬性(而不是section name)來肯定它們應該如何處理這個section。section名稱、類型和屬性將在section數據類型描述中進一步解釋。

Table 1 The sections of a __TEXT segment

Segment and section name	Contents
__ TEXT, __text	Executable machine code. The compiler generally places only executable code in this section, no tables or data of any sort. 可執行的機器代碼。編譯器一般只將可執行代碼放在這一節中，沒有任何類型的表或數據。
__ TEXT, __cstring	Constant C strings. A C string is a sequence of non-null bytes that ends with a null byte ('\0'). The static linker coalesces constant C string values, removing duplicates, when building the final product. 常數C字符串。C字符串是一個以空字節('\0')結尾的非空字節序列。靜態連接器在構建最終產品時合併常量C字符串值，刪除重複項。
__ TEXT, __picsymbol_stub	Position-independent indirect symbol stubs. See 「Dynamic Code Generation」 in Mach-O Programming Topics for more information. 位置無關的間接符號存根。有關更多信息，請參閱Mach-O編程主題中的「動態代碼生成」。
__ TEXT, __symbol_stub	Indirect symbol stubs. See 「Dynamic Code Generation」 in Mach-O Programming Topics for more information. 間接的象徵存根。有關更多信息，請參閱Mach-O編程主題中的「動態代碼生成」。
__ TEXT, __const	Initialized constant variables. The compiler places all nonrelocatable data declared const in this section. (The compiler typically places uninitialized constant variables in a zero-filled section.) 初始化常數變量。編譯器將在本節中放置全部聲明的const的不可重定位數據。(編譯器一般將未初始化的常量變量放在一個零填充的部分。)
__ TEXT, __literal4	4-byte literal values. The compiler places single-precision floating point constants in this section. The static linker coalesces these values, removing duplicates, when building the final product. With some architectures, it’s more efficient for the compiler to use immediate load instructions rather than adding to this section. 4字節的文本值。編譯器在本節中放置單精度浮點常量。靜態連接器在構建最終產品時合併這些值，刪除重複項。對於某些架構，編譯器使用當即加載指令比添加到本節更有效。
__ TEXT, __literal8	8-byte literal values. The compiler places double-precision floating point constants in this section. The static linker coalesces these values, removing duplicates, when building the final product. With some architectures, it’s more efficient for the compiler to use immediate load instructions rather than adding to this section. 8字節文字值。編譯器在本節中放置雙精度浮點常量。靜態連接器在構建最終產品時合併這些值，刪除重複項。對於某些架構，編譯器使用當即加載指令比添加到本節更有效。

Table 2 The sections of a __DATA segment

Segment and section name	Contents
__ DATA, __data	Initialized mutable variables, such as writable C strings and data arrays. 初始化可變變量，如可寫C字符串和數據數組。
__ DATA, __la_symbol_ptr	Lazy symbol pointers, which are indirect references to functions imported from a different file. See 「Dynamic Code Generation」 in Mach-O Programming Topics for more information. 懶加載符號指針，是對從不一樣文件導入的函數的間接引用。有關更多信息，請參閱Mach-O編程主題中的「動態代碼生成」。
__ DATA, __nl_symbol_ptr	Non-lazy symbol pointers, which are indirect references to data items imported from a different file. See 「Dynamic Code Generation」 in Mach-O Programming Topics for more information. 非懶加載符號指針，是對從其餘文件導入的函數的間接引用。有關詳細信息，請參閱Mach-O Programming Topics中的「Dynamic Code Generatio」。
__ DATA, __dyld	Placeholder section used by the dynamic linker. 動態連接器使用的佔位section
__ DATA, __const	Initialized relocatable constant variables. 初始化可重定位常量變量。
__ DATA, __mod_init_func	Module initialization functions. The C++ compiler places static constructors here. 模塊初始化方法，c++的靜態構造函數在這裏放
__ DATA, __mod_term_func	Module termination functions. 退出方法，相似析構函數
__ DATA, __bss	Data for uninitialized static variables (for example, static int i;). 未初始化靜態變量的數據（例如，static int i；）
__ DATA, __common	Uninitialized imported symbol definitions (for example, int i;) located in the global scope (outside of a function declaration). 位於全局範圍（函數聲明以外）中的未初始化全局符號的定義（例如，int i；)

Table 3 The sections of a __IMPORT segment

Segment and section name	Contents
__ IMPORT, __jump_table	Stubs for calls to functions in a dynamic library. 動態庫中函數調用的存根。
__ IMPORT, __pointers	Non-lazy symbol pointers, which are direct references to functions imported from a different file. 非懶加載符號指針，它們直接引用從其餘文件導入的函數

Note: Compilers or any tools that create Mach-O files are free to define additional section names. These additional names do not appear in Table

注意：編譯器或任何建立mach-o文件的工具均可以自由定義附加的節名。這些附加名稱不出如今表中

Data Types

This reference describes the data types that compose a Mach-O file. Values for integer types in all Mach-O data structures are written using the host CPU’s byte ordering scheme, except for fat_header (page 56) and fat_arch (page 56), which are written in big-endian byte order.

此參考描述組成mach-o文件的數據類型。全部mach-o數據結構中的整數類型的值都是使用主機cpu的字節順序方案編寫的，除了fat_header（第56頁）和fat_arch（第56頁）以外，它們都是以大端字節順序編寫的。

Header Data Structure

mach_header

Specifies the general attributes of a file. Appears at the beginning of object files targeted to 32-bit architectures. Declared in /usr/include/mach-o/loader.h. See also mach_header_64 (page 14).

/* * The 32-bit mach header appears at the very beginning of the object file for * 32-bit architectures. */
struct mach_header {
	uint32_t	magic;		/* mach magic number identifier */
	cpu_type_t	cputype;	/* cpu specifier */
	cpu_subtype_t	cpusubtype;	/* machine specifier */
	uint32_t	filetype;	/* type of file */
	uint32_t	ncmds;		/* number of load commands */
	uint32_t	sizeofcmds;	/* the size of all the load commands */
	uint32_t	flags;		/* flags */
};

/* Constant for the magic field of the mach_header (32-bit architectures) */
#define MH_MAGIC 0xfeedface /* the mach magic number */
#define MH_CIGAM 0xcefaedfe /* NXSwapInt(MH_MAGIC) */
複製代碼

• magic

  An integer containing a value identifying this file as a 32-bit Mach-O file. Use the constant MH_MAGIC if the file is intended for use on a CPU with the same endianness as the computer on which the compiler is running. The constant MH_CIGAM can be used when the byte ordering scheme of the target machine is the reverse of the host CPU.

  一個整數將文件標識爲32位Mach-O文件。若是文件要在與運行編譯器的計算機具備相同端點的CPU上使用，請使用常量MH_MAGIC。當目標機器的字節排序方案與主機cpu相反時，可使用常數MH_CIGAM。(大小端值不相同)

• cputype

  An integer indicating the architecture you intend to use the file on. Appropriate values include:

  一個整數，指示要在其上使用文件的體系結構。適當的值包括：

  #include <mach/machine.h>
  
  /* * Machine types known by all. */
   
  #define CPU_TYPE_ANY ((cpu_type_t) -1)
  
  #define CPU_TYPE_VAX ((cpu_type_t) 1)
  /* skip ((cpu_type_t) 2) */
  /* skip ((cpu_type_t) 3) */
  /* skip ((cpu_type_t) 4) */
  /* skip ((cpu_type_t) 5) */
  #define CPU_TYPE_MC680x0 ((cpu_type_t) 6)
  #define CPU_TYPE_X86 ((cpu_type_t) 7)
  #define CPU_TYPE_I386 CPU_TYPE_X86 /* compatibility */
  #define CPU_TYPE_X86_64 (CPU_TYPE_X86 | CPU_ARCH_ABI64)
  
  /* skip CPU_TYPE_MIPS ((cpu_type_t) 8) */
  /* skip ((cpu_type_t) 9) */
  #define CPU_TYPE_MC98000 ((cpu_type_t) 10)
  #define CPU_TYPE_HPPA ((cpu_type_t) 11)
  #define CPU_TYPE_ARM ((cpu_type_t) 12)
  #define CPU_TYPE_ARM64 (CPU_TYPE_ARM | CPU_ARCH_ABI64)
  #define CPU_TYPE_MC88000 ((cpu_type_t) 13)
  #define CPU_TYPE_SPARC ((cpu_type_t) 14)
  #define CPU_TYPE_I860 ((cpu_type_t) 15)
  /* skip CPU_TYPE_ALPHA ((cpu_type_t) 16) */
  /* skip ((cpu_type_t) 17) */
  #define CPU_TYPE_POWERPC ((cpu_type_t) 18)
  #define CPU_TYPE_POWERPC64 (CPU_TYPE_POWERPC | CPU_ARCH_ABI64)
  複製代碼

• cpusubtype

  An integer specifying the exact model of the CPU. To run on all PowerPC or x86 processors supported by the Mac OS X kernel, this should be set to CPU_SUBTYPE_POWERPC_ALL or CPU_SUBTYPE_I386_ALL.

  一個整數，指定CPU的確切型號。要在Mac OS X內核支持的全部PowerPC或x86處理器上運行，應將其設置爲CPU_Subtype_PowerPC_All或CPU_Subtype_i386_All。

  #define CPU_SUBTYPE_ARM_ALL ((cpu_subtype_t) 0)
  #define CPU_SUBTYPE_X86_ALL ((cpu_subtype_t)3)
  複製代碼

• filetype

  An integer indicating the usage and alignment of the file. Valid values for this field include:

  /* * A core file is in MH_CORE format and can be any in an arbritray legal * Mach-O file. * * Constants for the filetype field of the mach_header */
  #define MH_OBJECT 0x1 /* relocatable object file */
  #define MH_EXECUTE 0x2 /* demand paged executable file */
  #define MH_FVMLIB 0x3 /* fixed VM shared library file */
  #define MH_CORE 0x4 /* core file */
  #define MH_PRELOAD 0x5 /* preloaded executable file */
  #define MH_DYLIB 0x6 /* dynamically bound shared library */
  #define MH_DYLINKER 0x7 /* dynamic link editor */
  #define MH_BUNDLE 0x8 /* dynamically bound bundle file */
  #define MH_DYLIB_STUB 0x9 /* shared library stub for static */
  					/* linking only, no section contents */
  #define MH_DSYM 0xa /* companion file with only debug */
  					/* sections */
  #define MH_KEXT_BUNDLE 0xb /* x86_64 kexts */
  複製代碼

  • The MH_OBJECT file type is the format used for intermediate object files. It is a very compact format containing all its sections in one segment. The compiler and assembler usually create one MH_OBJECT file for each source code file. By convention, the file name extension for this format is .o.

    MH_OBJECT文件類型是用於中間對象文件的格式。它是一種很是緊湊的格式，將其全部部分都包含在一個段中。編譯器和彙編程序一般爲每一個源代碼文件建立一個MH_OBJECT文件。按照慣例，此格式的文件擴展名爲.o。

  • The MH_EXECUTE file type is the format used by standard executable programs.

    MH_EXECUTE file type是標準可執行程序使用的格式。

  • The MH_BUNDLE file type is the type typically used by code that you load at runtime (typically called bundles or plug-ins). By convention, the file name extension for this format is .bundle.

    MH_BUNDLE文件類型是運行時加載的代碼一般使用的類型（一般稱爲bundle或插件）。按照慣例，此格式的文件擴展名爲.bundle。

  • The MH_DYLIB file type is for dynamic shared libraries. It contains some additional tables to support multiple modules. By convention, the file name extension for this format is .dylib, except for the main shared library of a framework, which does not usually have a file name extension.

    MH_DYLIB文件類型用於動態共享庫。它包含一些額外的表來支持多個模塊。按照慣例，此格式的文件擴展名爲.dylib，但框架的主共享庫除外，它一般沒有文件擴展名。

  • The MH_PRELOAD file type is an executable format used for special-purpose programs that are not loaded by the Mac OS X kernel, such as programs burned into programmable ROM chips. Do not confuse this file type with the MH_PREBOUND flag, which is a flag that the static linker sets in the header structure to mark a prebound image.

    MH_PRELOAD文件類型是一種可執行格式，用於mac os x內核未加載的特殊用途程序，例如燒錄到可編程ROM芯片中的程序。不要將此文件類型與MH_PREBOUND標誌混淆，MH_PREBOUND標誌是靜態連接器在頭結構中設置的用於標記預綁定圖像的標誌。

  • The MH_CORE file type is used to store core files, which are traditionally created when a program crashes. Core files store the entire address space of a process at the time it crashed. You can later run gdb on the core file to figure out why the crash occurred.

    MH_CORE文件類型用於存儲核心文件，這些文件一般在程序崩潰時建立。核心文件存儲進程崩潰時的整個地址空間。您能夠稍後在覈心文件上運行gdb來找出崩潰的緣由。

  • The MH_DYLINKER file type is the type of a dynamic linker shared library. This is the type of the dyld file.

    MH_DYLINKER文件類型是動態連接器共享庫的類型。這是dyld文件的類型。

  • The MH_DSYM file type designates files that store symbol information for a corresponding binary file.

    MH_DSYM文件類型指定存儲相應二進制文件的符號信息的文件。

• ncmds

  An integer indicating the number of load commands following the header structure.

  指定架構load commands的個數

• sizeofcmds

  An integer indicating the number of bytes occupied by the load commands following the header structure. 全部load commands的size

• flags

  An integer containing a set of bit flags that indicate the state of certain optional features of the Mach-O file format. These are the masks you can use to manipulate this field:

  一個整數，包含一組位標誌，指示mach-o文件格式某些可選功能的狀態。如下是可用於操做此字段的掩碼：

  /* Constants for the flags field of the mach_header */
  #define MH_NOUNDEFS 0x1 /* the object file has no undefined references */
  #define MH_INCRLINK 0x2 /* the object file is the output of an incremental link against a base file and can't be link edited again */
  #define MH_DYLDLINK 0x4 /* the object file is input for the dynamic linker and can't be staticly link edited again */
  #define MH_BINDATLOAD 0x8 /* the object file's undefined references are bound by the dynamic linker when loaded. */
  #define MH_PREBOUND 0x10 /* the file has its dynamic undefined references prebound. */
  #define MH_SPLIT_SEGS 0x20 /* the file has its read-only and read-write segments split */
  #define MH_LAZY_INIT 0x40 /* the shared library init routine is to be run lazily via catching memory faults to its writeable segments (obsolete) */
  #define MH_TWOLEVEL 0x80 /* the image is using two-level name space bindings */
  #define MH_FORCE_FLAT 0x100 /* the executable is forcing all images to use flat name space bindings */
  #define MH_NOMULTIDEFS 0x200 /* this umbrella guarantees no multiple defintions of symbols in its sub-images so the two-level namespace hints can always be used. */
  #define MH_NOFIXPREBINDING 0x400 /* do not have dyld notify the prebinding agent about this executable */
  #define MH_PREBINDABLE 0x800 /* the binary is not prebound but can have its prebinding redone. only used when MH_PREBOUND is not set. */
  #define MH_ALLMODSBOUND 0x1000 /* indicates that this binary binds to all two-level namespace modules of its dependent libraries. only used when MH_PREBINDABLE and MH_TWOLEVEL are both set. */ 
  #define MH_SUBSECTIONS_VIA_SYMBOLS 0x2000/* safe to divide up the sections into sub-sections via symbols for dead code stripping */
  #define MH_CANONICAL 0x4000 /* the binary has been canonicalized via the unprebind operation */
  #define MH_WEAK_DEFINES 0x8000 /* the final linked image contains external weak symbols */
  #define MH_BINDS_TO_WEAK 0x10000 /* the final linked image uses weak symbols */
  
  #define MH_ALLOW_STACK_EXECUTION 0x20000/* When this bit is set, all stacks in the task will be given stack execution privilege. Only used in MH_EXECUTE filetypes. */
  #define MH_ROOT_SAFE 0x40000 /* When this bit is set, the binary declares it is safe for use in processes with uid zero */
                                           
  #define MH_SETUID_SAFE 0x80000 /* When this bit is set, the binary declares it is safe for use in processes when issetugid() is true */
  
  #define MH_NO_REEXPORTED_DYLIBS 0x100000 /* When this bit is set on a dylib, the static linker does not need to examine dependent dylibs to see if any are re-exported */
  #define MH_PIE 0x200000 /* When this bit is set, the OS will load the main executable at a random address. Only used in MH_EXECUTE filetypes. */
  #define MH_DEAD_STRIPPABLE_DYLIB 0x400000 /* Only for use on dylibs. When linking against a dylib that has this bit set, the static linker will automatically not create a LC_LOAD_DYLIB load command to the dylib if no symbols are being referenced from the dylib. */
  #define MH_HAS_TLV_DESCRIPTORS 0x800000 /* Contains a section of type S_THREAD_LOCAL_VARIABLES */
  
  #define MH_NO_HEAP_EXECUTION 0x1000000 /* When this bit is set, the OS will run the main executable with a non-executable heap even on platforms (e.g. i386) that don't require it. Only used in MH_EXECUTE filetypes. */
  
  #define MH_APP_EXTENSION_SAFE 0x02000000 /* The code was linked for use in an application extension. */
  
  #define MH_NLIST_OUTOFSYNC_WITH_DYLDINFO 0x04000000 /* The external symbols listed in the nlist symbol table do not include all the symbols listed in the dyld info. */
  
  #define MH_SIM_SUPPORT 0x08000000 /* Allow LC_MIN_VERSION_MACOS and LC_BUILD_VERSION load commands with the platforms macOS, macCatalyst, iOSSimulator, tvOSSimulator and watchOSSimulator. */
  					   
  #define MH_DYLIB_IN_CACHE 0x80000000 /* Only for use on dylibs. When this bit is set, the dylib is part of the dyld shared cache, rather than loose in the filesystem. */
  複製代碼

  • MH_NOUNDEFS—The object file contained no undefined references when it was built.

    ​ 對象文件在生成時不包含未定義的引用

  • MH_INCRLINK The object file is the output of an incremental link against a base file and cannot be linked again

    對象文件是對基本文件的增量連接的輸出，而且沒法再次連接

  • MH_DYLDLINK

    • The file is input for the dynamic linker and cannot be statically linked again.

      該文件是動態連接器的輸入，不能再次靜態連接。

  • MH_TWOLEVEL

    • The image is using two-level namespace bindings

      Image正在使用兩級命名空間綁定

  • MH_BINDATLOAD

    • The dynamic linker should bind the undefined references when the file

      is loaded.

      動態連接器應該在文件加載時綁定未定義的引用

  • MH_PREBOUND

    • The file’s undefined references are prebound.

      文件的未定義引用是預先綁定的。

  • MH_PREBINDABLE

    • This file is not prebound but can have its prebinding redone. Used only when MH_PREBEOUND is not set
    • 此文件不是預綁定的，但能夠從新進行預綁定。僅在未設置MH_PREBEOUND時使用

  • MH_NOFIXPREBINDING

    • The dynamic linker doesn’t notify the prebinding agent about this executable.

      動態連接器不會將此可執行文件通知預綁定代理。

  • MH_ALLMODSBOUND

    • Indicates that this binary binds to all two-level namespace modules of its dependent libraries. Used only when MH_PREBINDABLE and MH_TWOLEVEL are set.
    • 指示此二進制文件綁定到其依賴庫的全部兩級命名空間模塊。僅當設置了MH_PREBINDABLE和MH_TWOLEVEL時使用。

  • MH_CANONICAL

    • This file has been canonicalized by unprebinding—clearing prebinding information from the file. See the redo_prebinding man page for details
    • 此文件已經過取消綁定從文件中清除預綁定信息來規範化。有關詳細信息，請參閱重作預綁定手冊頁

  • MH_SPLIT_SEGS

    • The file has its read-only and read-write segments split.
    • 文件的只讀段和讀寫段被拆分。

  • MH_FORCE_FLAT

    • The executable is forcing all images to use flat namespace bindings.
    • 可執行文件正在強制全部映像使用平面命名空間綁定。

  • MH_SUBSECTIONS_VIA_SYMBOLS

    • The sections of the object file can be divided into individual blocks. These blocks are dead-stripped if they are not used by other code. See 「Linking」 in Xcode User Guide for details.
    • 對象文件的各個部分能夠劃分爲單獨的塊。若是其餘代碼不使用這些塊，則它們將被徹底剝離。有關詳細信息，請參閱Xcode用戶指南中的「連接」。

  • MH_NOMULTIDEFS

    • This umbrella guarantees there are no multiple definitions of symbols in its subimages. As a result, the two-level namespace hints can always be used.
    • 這把傘保證了它的子圖像中沒有符號的多重定義。所以，始終可使用兩級命名空間提示。

  • MH_PIE

    • When this bit is set, the OS will load the main executable at a random address. Only used in MH_EXECUTE filetypes
    • 隨機地址分佈，ASLR 用於MH_EXECUTE filetype

• Special Considerations

  For all file types, except MH_OBJECT, segments must be aligned on page boundaries for the given CPU architecture: 4096 bytes for PowerPC and x86 processors. This allows the kernel to page virtual memory directly from the segment into the address space of the process. The header and load commands must be aligned as part of the data of the first segment stored on disk (which would be the __TEXT segment, in the file types described in filetype).

  對於除MH_OBJECT之外的全部文件類型，對於給定的cpu體系結構，段必須在頁面邊界上對齊：對於powerpc和x86處理器，爲4096字節。這容許內核將虛擬內存直接從段分頁到進程的地址空間。header和load commands存儲在磁盤上的第一個段的數據的一部分對齊（在filetype中描述的文件類型中，第一個段是__TEXT段)

Load Command Data Structures

The load command structures are located directly after the header of the object file, and they specify both the logical structure of the file and the layout of the file in virtual memory. Each load command begins with fields that specify the command type and the size of the command data.

加載命令結構直接位於對象文件頭的後面，它們指定文件的邏輯結構和虛擬內存中文件的佈局。每一個加載命令都以指定命令類型和命令數據大小的字段開頭。

load_command

Contains fields that are common to all load commands.

包含全部加載命令通用的字段。

struct load_command {
	uint32_t cmd;		/* type of load command */
	uint32_t cmdsize;	/* total size of command in bytes */
};
複製代碼

Fields

• cmd

  An integer indicating the type of load command. Table 4 lists the valid load command types.

• cmdsize

  An integer specifying the total size in bytes of the load command data structure. Each load command structure contains a different set of data, depending on the load command type, so each might have a different size. In 32-bit architectures, the size must always be a multiple of 4; in 64-bit architectures, the size must always be a multiple of 8. If the load command data does not divide evenly by 4 or 8 (depending on whether the target architecture is 32-bit or 64-bit, respectively), add bytes containing zeros to the end until it does.

  一個整數，指定加載命令數據結構的總大小（字節）。每一個加載命令結構都包含不一樣的數據集，具體取決於加載命令類型，所以每一個數據集的大小可能不一樣。在32位體系結構中，大小必須始終是4的倍數；在64位體系結構中，大小必須始終是8的倍數。若是加載命令數據沒有被4或8等分（分別取決於目標體系結構是32位仍是64位），請在末尾添加包含零的字節，直到它等分爲止。

Discussion

Table 4 lists the valid load command types, with links to the full data structures for each type.

表4列出了有效的加載命令類型，每種類型都有指向完整數據結構的連接。

Table 4 Mach-O load commands

Commands	Data Structures	Purpose
LC_UUID	uuid_command	Specifies the 128-bit UUID for an image or its corresponding dSYM file. 爲image或其相應的dSYM文件指定128位uuid
LC_SEGMENT	segment_command	Defines a segment of this file to be mapped into the address space of the process that loads this file. It also includes all the sections contained by the segment. 定義要映射到加載此文件的進程的地址空間中的此文件段。它還包括該段所包含的全部部分。
LC_SEGMENT_64	segment_command_64	Defines a 64-bit segment of this file to be mapped into the address space of the process that loads this file. It also includes all the sections contained by the segment.
LC_SYMTAB	symtab_command	Specifies the symbol table for this file. This information is used by both static and dynamic linkers when linking the file, and also by debuggers to map symbols to the original source code files from which the symbols were generated. 指定此文件的符號表。靜態和動態連接器在連接文件時都會使用此信息，調試器也會使用此信息將符號映射到生成符號的原始源代碼文件。
LC_DYSYMTAB	dysymtab_command	Specifies additional symbol table information used by the dynamic linker. 指定動態連接器使用的其餘符號表信息。
LC_THREAD LC_UNIXTHREAD	thread_command	For an executable file, the LC_UNIXTHREAD command defines the initial thread state of the main thread of the process. LC_THREAD is similar to LC_UNIXTHREAD but does not cause the kernel to allocate a stack. 對於可執行文件，LC_UNIXTHREAD命令定義進程主線程的初始線程狀態。LC_THREAD相似於LC_UNIXTHREAD，但不會致使內核分配堆棧。
LC_LOAD_DYLIB	dylib_command	Defines the name of a dynamic shared library that this file links against. 定義此文件連接所針對的動態共享庫的名稱。
LC_ID_DYLIB	dylib_command	Specifies the install name of a dynamic shared library. 指定動態共享庫的安裝名稱。
LC_PREBOUND_DYLIB	prebound_dylib_command	For a shared library that this executable is linked prebound against, specifies the modules in the shared library that are used. 對於此可執行文件連接到的共享庫，請指定共享庫中使用的模塊。
LC_LOAD_DYLINKER	dylinker_command	Specifies the dynamic linker that the kernel executes to load this file. 指定內核執行以加載此文件的動態連接器。
LC_ID_DYLINKER	dylinker_command	Identifies this file as a dynamic linker. 將此文件標識爲動態連接器。
LC_ROUTINES	routines_command	Contains the address of the shared library initialization routine (specified by the linker’s -init option). 包含共享庫初始化例程的地址（由連接器的-init選項指定）。
LC_ROUTINES_64	routines_command_64	Contains the address of the shared library 64-bit initialization routine (specified by the linker’s -init option).
LC_TWOLEVEL_HINTS	twolevel_hints_command	Contains the two-level namespace lookup hint table. 包含兩級命名空間查找提示表。
LC_SUB_FRAMEWORK	sub_framework_command	Identifies this file as the implementation of a subframework of an umbrella framework. The name of the umbrella framework is stored in the string parameter. 將此文件標識爲傘形框架的子框架的實現。傘形框架的名稱存儲在字符串參數中。
LC_SUB_UMBRELLA	sub_umbrella_command	Specifies a file that is a subumbrella of this umbrella framework. 指定做爲此傘形框架的子傘形結構的文件。
LC_SUB_LIBRARY	sub_library_command	Identifies this file as the implementation of a sublibrary of an umbrella framework. The name of the umbrella framework is stored in the string parameter. Note that Apple has not defined a supported location for sublibraries. 將此文件標識爲傘形框架的子庫的實現。傘形框架的名稱存儲在字符串參數中。請注意，Apple還沒有爲子庫定義支持的位置。
LC_SUB_CLIENT	sub_client_command	A subframework can explicitly allow another framework or bundle to link against it by including an LC_SUB_CLIENT load command containing the name of the framework or a client name for a bundle. 子框架能夠經過包含lc_sub_client load命令顯式地容許另外一個框架或捆綁包與之連接，該命令包含框架的名稱或捆綁包的客戶端名稱。

• uuid_command

  Specifies the 128-bit universally unique identifier (UUID) for an image or for its corresponding dSYM file.

  爲image或其相應的dSYM文件指定128位uuid

  /* * The uuid load command contains a single 128-bit unique random number that * identifies an object produced by the static link editor. */
  struct uuid_command {
      uint32_t	cmd;		/* LC_UUID */
      uint32_t	cmdsize;	/* sizeof(struct uuid_command) */
      uint8_t	uuid[16];	/* the 128-bit uuid */
  };
  複製代碼

  Fields

  • cmd Set to LC_UUID for this structure.

  • cmdsize Set to sizeof(uuid_command).

  • uuid

    ​ 128-bit unique identifier

  Declared In

  /usr/include/mach-o/loader.h

• segment_command

  Specifies the range of bytes in a 32-bit Mach-O file that make up a segment. Those bytes are mapped by the loader into the address space of a program. Declared in /usr/include/mach-o/loader.h.

  指定組成段的32位mach-o文件中的字節範圍。這些字節由加載程序映射到程序的地址空間中

  struct segment_command { /* for 32-bit architectures */
  	uint32_t	cmd;		/* LC_SEGMENT */
  	uint32_t	cmdsize;	/* includes sizeof section structs */
  	char		segname[16];	/* segment name */
  	uint32_t	vmaddr;		/* memory address of this segment */
  	uint32_t	vmsize;		/* memory size of this segment */
  	uint32_t	fileoff;	/* file offset of this segment */
  	uint32_t	filesize;	/* amount to map from the file */
  	vm_prot_t	maxprot;	/* maximum VM protection */
  	vm_prot_t	initprot;	/* initial VM protection */
  	uint32_t	nsects;		/* number of sections in segment */
  	uint32_t	flags;		/* flags */
  };
  
  /* * The 64-bit segment load command indicates that a part of this file is to be * mapped into a 64-bit task's address space. If the 64-bit segment has * sections then section_64 structures directly follow the 64-bit segment * command and their size is reflected in cmdsize. */
  struct segment_command_64 { /* for 64-bit architectures */
  	uint32_t	cmd;		/* LC_SEGMENT_64 */
  	uint32_t	cmdsize;	/* includes sizeof section_64 structs */
  	char		segname[16];	/* segment name */
  	uint64_t	vmaddr;		/* memory address of this segment */
  	uint64_t	vmsize;		/* memory size of this segment */
  	uint64_t	fileoff;	/* file offset of this segment */
  	uint64_t	filesize;	/* amount to map from the file */
  	vm_prot_t	maxprot;	/* maximum VM protection */
  	vm_prot_t	initprot;	/* initial VM protection */
  	uint32_t	nsects;		/* number of sections in segment */
  	uint32_t	flags;		/* flags */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. Set to LC_SEGMENT for this structure.

  • cmdsize

    Common to all load command structures. For this structure, set this field to sizeof(segment_command) plus the size of all the section data structures that follow (sizeof(segment_command + (sizeof(section) * segment->nsect))).

  • segname

    A C string specifying the name of the segment. The value of this field can be any sequence of ASCII characters, although segment names defined by Apple begin with two underscores and consist of capital letters (as in ___TEXT and ___DATA). This field is fixed at 16 bytes in length.

    指定段名稱的C字符串。此字段的值能夠是任意一個ASCII字符序列，儘管Apple定義的段名稱以兩個下劃線開頭，並由大寫字母組成（如在「_______TEXT」和"_____DATA"中）。此字段的長度固定爲16字節。

  • vmaddr

    Indicates the starting virtual memory address of this segment.

    指示此段的起始虛擬內存地址。

  • vmsize

    Indicates the number of bytes of virtual memory occupied by this segment. See also the description of filesize, below.

    指示此段佔用的虛擬內存字節數。另請參見下面的文件大小說明。

  • fileoff

    Indicates the offset in this file of the data to be mapped at vmaddr.

    指示此文件中要在vmaddr映射的數據的偏移量。

  • filesize

    Indicates the number of bytes occupied by this segment on disk. For segments that require more memory at runtime than they do at build time, vmsize can be larger than filesize. For example, the __ PAGEZERO segment generated by the linker for MH_EXECUTABLE files has a vmsize of 0x1000 but a filesize of 0. Because _ PAGEZERO contains no data, there is no need for it to occupy any space until runtime. Also, the static linker often allocates uninitialized data at the end of the __DATA segment; in this case, the vmsize is larger than the filesize. The loader guarantees that any memory of this sort is initialized with zeros.

    指示磁盤上此段佔用的字節數。對於運行時比構建時須要更多內存的段，vmsize能夠大於filesize。例如，連接器爲MH_EXECUTABLE文件生成的u pagezero段的vmsize爲0x1000，而filesize爲0。由於pagezero不包含任何數據，因此在運行以前不須要佔用任何空間。此外，靜態連接器一般在數據段末尾分配未初始化的數據；在這種狀況下，vmsize大於filesize。加載程序保證這類內存都是用零初始化的。

  • maxprot

    Specifies the maximum permitted virtual memory protections of this segment.

    指定此段容許的最大虛擬內存保護。

  • initprot

    Specifies the initial virtual memory protections of this segment.

    指定此段的初始虛擬內存保護。

  • nsects

    Indicates the number of section data structures following this load command.

    指示此load commands命令下的section數量

  • flags

    Defines a set of flags that affect the loading of this segment:

    • SG_HIGHVM—The file contents for this segment are for the high part of the virtual memory space; the low part is zero filled (for stacks in core files).
    • SG_NORELOC—This segment has nothing that was relocated in it and nothing relocated to it. It may be safely replaced without relocation.
    • 定義一組影響此段加載的標誌： SG_HIGHVM—此段的文件內容用於虛擬內存空間的高部分；低部分爲零填充（用於核心文件中的堆棧）。 SG_NORELOC-該段沒有從新安置的任何東西，也沒有從新安置的任何東西。可安全更換，無需從新安置。

• section

  Defines the elements used by a 32-bit section. Directly following a segment_command data structure is an array of section data structures, with the exact count determined by the nsects field of the segment_command (page 20) structure. Declared in /usr/include/mach-o/loader.h.

  定義32位節使用的元素。段命令數據結構的正後方是一個段數據結構數組，其精確計數由段命令（第20頁）結構的nsects字段肯定。在/usr/include/mach-o/loader.h中聲明。

  struct section { /* for 32-bit architectures */
  	char		sectname[16];	/* name of this section */
  	char		segname[16];	/* segment this section goes in */
  	uint32_t	addr;		/* memory address of this section */
  	uint32_t	size;		/* size in bytes of this section */
  	uint32_t	offset;		/* file offset of this section */
  	uint32_t	align;		/* section alignment (power of 2) */
  	uint32_t	reloff;		/* file offset of relocation entries */
  	uint32_t	nreloc;		/* number of relocation entries */
  	uint32_t	flags;		/* flags (section type and attributes)*/
  	uint32_t	reserved1;	/* reserved (for offset or index) */
  	uint32_t	reserved2;	/* reserved (for count or sizeof) */
  };
  
  struct section_64 { /* for 64-bit architectures */
  	char		sectname[16];	/* name of this section */
  	char		segname[16];	/* segment this section goes in */
  	uint64_t	addr;		/* memory address of this section */
  	uint64_t	size;		/* size in bytes of this section */
  	uint32_t	offset;		/* file offset of this section */
  	uint32_t	align;		/* section alignment (power of 2) */
  	uint32_t	reloff;		/* file offset of relocation entries */
  	uint32_t	nreloc;		/* number of relocation entries */
  	uint32_t	flags;		/* flags (section type and attributes)*/
  	uint32_t	reserved1;	/* reserved (for offset or index) */
  	uint32_t	reserved2;	/* reserved (for count or sizeof) */
  	uint32_t	reserved3;	/* reserved */
  };
  複製代碼

  Fields

  • sectname

    A string specifying the name of this section. The value of this field can be any sequence of ASCII characters, although section names defined by Apple begin with two underscores and consist of lowercase letters (as in __text and __data). This field is fixed at 16 bytes in length.

    指定此節名稱的字符串。此字段的值能夠是任意一個ASCII字符序列，儘管Apple定義的節名稱以兩個下劃線開頭，而且由小寫字母組成（如文本和數據）。此字段的長度固定爲16字節。

  • segname

    A string specifying the name of the segment that should eventually contain this section. For compactness, intermediate object files—files of type MH_OBJECT—contain only one segment, in which all sections are placed. The static linker places each section in the named segment when building the final product (any file that is not of type MH_OBJECT).

    指定最終應包含此節的段的名稱的字符串。對於緊湊性，MH_OBJECT類型的中間對象文件只包含一個段，其中放置了全部的段。靜態連接器在生成最終產品（任何不屬於MH_OBJECT類型的文件）時將每一個部分放置在命名段中。

  • addr

    An integer specifying the virtual memory address of this section.

    指定此節的虛擬內存地址的整數。

  • size

    An integer specifying the size in bytes of the virtual memory occupied by this section.

    一個整數，指定此節佔用的虛擬內存的字節大小。

  • offset

    An integer specifying the offset to this section in the file.

    一個整數，指定文件中此節的偏移量。

  • align

    An integer specifying the section’s byte alignment. Specify this as a power of two; for example, a section with 8-byte alignment would have an align value of 3 (2 to the 3rd power equals 8).

    指定節字節對齊方式的整數。將其指定爲2的冪；例如，具備8字節對齊的節的對齊值爲3（2到3的冪等於8）。

  • reloff

    An integer specifying the file offset of the first relocation entry for this section.

    一個整數，指定此節的第一個重定位項的文件偏移量。

  • nreloc

    An integer specifying the number of relocation entries located at reloff for this section.

    一個整數，指定位於此節的reloff處的重定位條目數。

  • flags

    An integer divided into two parts. The least significant 8 bits contain the section type, while the most significant 24 bits contain a set of flags that specify other attributes of the section. These types and flags are primarily used by the static linker and file analysis tools, such as otool, to determine how to modify or display the section. These are the possible types:

    分紅兩部分的整數。最低有效8位包含節類型，而最高有效24位包含指定節的其餘屬性的標誌集。這些類型和標誌主要由靜態連接器和文件分析工具（如otool）使用，以肯定如何修改或顯示節。如下是可能的類型：

    • S_REGULAR

      This section has no particular type. The standard tools create a __TEXT,__text section of this type.

      此節沒有特定類型。標準工具會建立此類型的文本節。

    • S_ZEROFILL

      Zero-fill-on-demand section—when this section is first read from or written to, each page within is automatically filled with bytes containing zero.

      零按需填充節第一次讀取或寫入此節時，其中的每一頁都會自動填充包含零的字節。

    • S_CSTRING_LITERALS

      This section contains only constant C strings. The standard tools create a __TEXT,__cstring section of this type.

      這個section僅包含C常量字符串。標準工具在此type下建立了__TEXT, __string

    • S_4BYTE_LITERALS

      This section contains only constant values that are 4 bytes long. The standard tools create a __TEXT,__literal4 section of this type.

    • S_8BYTE_LITERALS

      This section contains only constant values that are 8 bytes long. The standard tools create a __TEXT,__literal8 section of this type.

    • S_LITERAL_POINTERS

      This section contains only pointers to constant values.

      本節僅包含指向常量值的指針。

    • S_NON_LAZY_SYMBOL_POINTERS

      This section contains only non-lazy pointers to symbols.

      The standard tools create a section of the __DATA,__nl_symbol_ptrs section of this type.

      此部分僅包含指向符號的非懶加載指針。

    • S_LAZY_SYMBOL_POINTERS

      This section contains only lazy pointers to symbols. The

      standard tools create a __DATA,__la_symbol_ptrs section of this type.

      此部分僅包含指向符號的懶加載指針。

    • S_SYMBOL_STUBS

      This section contains symbol stubs. The standard tools create __TEXT,__symbol_stub and __TEXT,__picsymbol_stub sections of this type. See 「Dynamic Code Generation」 in Mach-O Programming Topics for more information.

      本節包含符號存根

    • S_MOD_INIT_FUNC_POINTERS

      This section contains pointers to module initialization functions. The standard tools create __DATA,__mod_init_func sections of this type.

      包含模塊初始化方法的指針

    • S_MOD_TERM_FUNC_POINTERS

      This section contains pointers to module termination functions. The standard tools create __DATA,__mod_term_func sections of this type.

      包含模塊結束方法的指針

    • S_COALESCED

      This section contains symbols that are coalesced by the static linker and possibly the dynamic linker. More than one file may contain coalesced definitions of the same symbol without causing multiple-defined-symbol errors.

      此部分包含由靜態連接器（可能還有動態連接器）合併的符號。多個文件可能包含同一符號的合併定義，但不會致使多個定義的符號錯誤。

    • S_GB_ZEROFILL

      This is a zero-filled on-demand section. It can be larger than 4 GB. This section must be placed in a segment containing only zero-filled sections. If you place a zero-filled section in a segment with non–zero-filled sections, you may cause those sections to be unreachable with a 31-bit offset. That outcome stems from the fact that the size of a zero-filled section can be larger than 4 GB (in a 32-bit address space). As a result of this, the static linker would be unable to build the output file. See segment_command (page 20) for more information.

      這是一個零填充的按需部分。它能夠大於4 GB。此節必須放在只包含零填充節的段中。若是將零填充部分放在具備非零填充部分的段中，則可能會致使以31位偏移量沒法訪問這些部分。這一結果源於這樣一個事實：零填充部分的大小能夠大於4GB（在32位地址空間中）。所以，靜態連接器將沒法生成輸出文件。有關更多信息，請參閱StEngSub命令（第20頁）。

    The following are the possible attributes of a section:

    • S_ATTR_PURE_INSTRUCTIONS

      This section contains only executable machine instructions. The standard tools set this flag for the sections __TEXT,__text, __TEXT,__symbol_stub, and __TEXT,__picsymbol_stub.

      本節僅包含可執行的機器指令。

    • S_ATTR_SOME_INSTRUCTIONS

      This section contains executable machine instructions.

    • S_ATTR_NO_TOC

      This section contains coalesced symbols that must not be placed in the

      table of contents (SYMDEF member) of a static archive library.

    • S_ATTR_EXT_RELOC

      This section contains references that must be relocated. These references refer to data that exists in other files (undefined symbols). To support external relocation, the maximum virtual memory protections of the segment that contains this section must allow both reading and writing.

      本節包含必須從新定位的引用。這些引用引用其餘文件中存在的數據（未定義的符號）。爲了支持外部重定位，包含此節的段的最大虛擬內存保護必須容許讀寫。

    • S_ATTR_LOC_RELOC

      This section contains references that must be relocated. These references refer to data within this file.

      本節包含必須從新定位的引用。這些引用引用此文件中的數據。

    • S_ATTR_STRIP_STATIC_SYMS

      The static symbols in this section can be stripped if the MH_DYLDLINK flag of the image’s mach_header (page 12) header structure is set.

    • S_ATTR_NO_DEAD_STRIP

      This section must not be dead-stripped. See 「Linking」 in Xcode User Guide for details.

    • S_ATTR_LIVE_SUPPORT

      This section must not be dead-stripped if they reference code that is live, but the reference is undetectable.

  • reserved1

    An integer reserved for use with certain section types. For symbol pointer sections and symbol stubs sections that refer to indirect symbol table entries, this is the index into the indirect table for this section’s entries. The number of entries is based on the section size divided by the size of the symbol pointer or stub. Otherwise, this field is set to 0.

    保留用於某些節類型的整數。對於引用間接符號表項的符號指針節和符號存根節，這是指向該節項的間接表的索引。條目的數目基於節大小除以符號指針或存根的大小。不然，此字段設置爲0。

  • reserved2

    For sections of type S_SYMBOL_STUBS, an integer specifying the size (in bytes) of the symbol

    stub entries contained in the section. Otherwise, this field is reserved for future use and should be set to 0.

    對於S_SYMBOL_STUBS類型的section，使用整數指定符號的大小(以字節爲單位) section中包含的stub條目。不然，此字段將保留以供未來使用，並應設置爲0。

  Discussion

  Each section in a Mach-O file has both a type and a set of attribute flags. In intermediate object files, the type and attributes determine how the static linker copies the sections into the final product. Object file analysis tools (such as otool) use the type and attributes to determine how to read and display the sections. Some section types and attributes are used by the dynamic linker.

  These are important static-linking variants of the symbol type and attributes:

  mach-o文件中的每一個部分都有一個類型和一組屬性標誌。在中間對象文件中，類型和屬性決定靜態連接器如何將節複製到最終產品中。對象文件分析工具（如otool）使用類型和屬性來肯定如何讀取和顯示節。動態連接器使用某些節類型和屬性。 這些是符號類型和屬性的重要靜態連接變體：

  • Regular sections. In a regular section, only one definition of an external symbol may exist in intermediate object files. The static linker returns an error if it finds any duplicate external symbol definitions.

    在常規部分中，中間對象文件中只能存在外部符號的一個定義。若是發現任何重複的外部符號定義，靜態連接器將返回錯誤。

  • Coalesced sections. In the final product, the static linker retains only one instance of each symbol defined in coalesced sections. To support complex language features (such as C++ vtables and RTTI) the compiler may create a definition of a particular symbol in every intermediate object file. The static linker and the dynamic linker would then reduce the duplicate definitions to the single definition used by the program.

    在最終產品中，靜態連接器只保留合併部分中定義的每一個符號的一個實例。爲了支持複雜的語言特性（如C++ VTABLE和RTTI），編譯器能夠在每一箇中間對象文件中建立一個特定符號的定義。靜態連接器和動態連接器將把重複的定義減小到程序使用的單個定義。

  • Coalesced sections with weak definitions Weak symbol definitions may appear only in coalesced sections. When the static linker finds duplicate definitions for a symbol, it discards any coalesced symbol definition that has the weak definition attribute set (see nlist (page 39)). If there are no non-weak definitions, the first weak definition is used instead. This feature is designed to support C++ templates; it allows explicit template instantiations to override implicit ones. The C++ compiler places explicit definitions in a regular section, and it places implicit definitions in a coalesced section, marked as weak definitions. Intermediate object files (and thus static archive libraries) built with weak definitions can be used only with the static linker in Mac OS X v10.2 and later. Final products (applications and shared libraries) should not contain weak definitions if they are expected to be used on earlier versions of Mac OS X.

    弱符號定義只能出如今合併部分中。當靜態連接器發現符號的重複定義時，它將丟棄任何具備弱定義屬性集的合併符號定義（請參閱nlist（第39頁））。若是沒有非弱定義，則使用第一個弱定義。該特性被設計爲支持C++模板；它容許顯式模板實例化來重寫隱式模板。C++編譯器將顯式定義放在一個常規的部分中，它將隱含的定義放在一個合併的區段中，標記爲弱定義。使用弱定義構建的中間對象文件（以及靜態存檔庫）只能與Mac OS X v10.2及更高版本中的靜態連接器一塊兒使用。若是最終產品（應用程序和共享庫）預期在早期版本的MacOSX上使用，則不該包含弱定義。

• twolevel_hints_command

  Defines the attributes of a LC_TWOLEVEL_HINTS load command

  /* * The twolevel_hints_command contains the offset and number of hints in the * two-level namespace lookup hints table. */
  struct twolevel_hints_command {
      uint32_t cmd;	/* LC_TWOLEVEL_HINTS */
      uint32_t cmdsize;	/* sizeof(struct twolevel_hints_command) */
      uint32_t offset;	/* offset to the hint table */
      uint32_t nhints;	/* number of hints in the hint table */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. Set to LC_TWOLEVEL_HINTS for this structure.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(twolevel_hints_command).

  • offset

    An integer specifying the byte offset from the start of this file to an array of

    twolevel_hint (page 30) data structures, known as the two-level namespace hint table.

    在文件內的offset

  • nhints

    The number of twolevel_hint data structures located at offset.

    位於偏移量的二級提示數據結構的數目。

  Discussion

  The static linker adds the LC_TWOLEVEL_HINTS load command and the two-level namespace hint table to the output file when building a two-level namespace image.

  討論 靜態連接器在生成兩級命名空間映像時將lc_twowlevel_hints load命令和兩級命名空間提示表添加到輸出文件中。

  Special Considerations By default, ld does not include the LC_TWOLEVEL_HINTS command or the two-level namespace hint table in an MH_BUNDLE file because the presence of this load command causes the version of the dynamic linker shipped with Mac OS X v10.0 to crash. If you know the code will run only on Mac OS X v10.1 and later, you should explicitly enable the two-level namespace hint table. See -twolevel_namespace_hints in the ld man page for more information.

  特殊注意事項 默認狀況下，ld不會在MH_BUNDLE文件中包含lc_twolevel_hint命令或兩級名稱空間提示表，由於這個load命令的存在會致使Mac OS X v10.0附帶的動態連接器版本崩潰。若是您知道代碼只在Mac OS X v10.1及更高版本上運行，那麼應該顯式啓用兩級名稱空間提示表。有關更多信息，請參見ld手冊頁中的- twolevel_namespace_tips。

• twolevel_hint

  Specifies an entry in the two-level namespace hint table. Declared in /usr/include/mach-o/loader.h.

  struct twolevel_hint {
      uint32_t 
  	isub_image:8,	/* index into the sub images */
  	itoc:24;	/* index into the table of contents */
  };
  複製代碼

  Fields

  • isub_image

    The subimage in which the symbol is defined. It is an index into the list of images that make up the umbrella image. If this field is 0, the symbol is in the umbrella image itself. If the image is not an umbrella framework or library, this field is 0.

    定義符號的subimage。它是組成雨傘圖像的圖像列表的索引。若是此字段爲0，則符號在傘圖像自己中。若是圖像不是傘形框架或庫，則此字段爲0。

  • itoc

    The symbol index into the table of contents of the image specified by the isub_image field.

    由isub_image字段指定的圖像目錄中的符號索引。

  Discussion

  The two-level namespace hint table provides the dynamic linker with suggested positions to start searching for symbols in the libraries the current image is linked against.

  Every undefined symbol (that is, every symbol of type N_UNDF or N_PBUD) in a two-level namespace image has a corresponding entry in the two-level hint table, at the same index.

  The static linker adds the LC_TWOLEVEL_HINTS load command and the two-level namespace hint table to the output file when building a two-level namespace image.

  By default, the linker does not include the LC_TWOLEVEL_HINTS command or the two-level namespace hint table in an MH_BUNDLE file, because the presence of this load command causes the version of the dynamic linker shipped with Mac OS X v10.0 to crash. If you know the code will run only on Mac OS X v10.1 and later, you should explicitly enable the two-level namespace hints. See the linker documentation for more information. 兩級命名空間提示表爲動態連接器提供建議的位置，以便開始在當前圖像所連接的庫中搜索符號。 兩級命名空間映像中的每一個未定義符號（即，類型爲n_undf或n_pbud的每一個符號）在兩級提示表中的同一索引處都有相應的項。 靜態連接器在生成兩級命名空間映像時將lc_twowlevel_hints load命令和兩級命名空間提示表添加到輸出文件中。 默認狀況下，連接器不包括mh_捆綁包文件中的lc_two level_hints命令或兩級命名空間提示表，由於此加載命令的存在會致使mac os x v10.0附帶的動態連接器版本崩潰。若是您知道代碼將只在macosxv10.1及更高版本上運行，那麼應該顯式地啓用兩級命名空間提示。有關詳細信息，請參閱連接器文檔。

• lc_str

  Defines a variable-length string. Declared in /usr/include/mach-o/loader.h.

  union lc_str {
  	uint32_t	offset;	/* offset to the string */
  #ifndef __LP64__
  	char		*ptr;	/* pointer to the string */
  #endif 
  };
  複製代碼

  Fields

  • offset

    A long integer. A byte offset from the start of the load command that contains this string to the start of the string data.

    一個長整數。從包含此字符串的加載命令開始到字符串數據開始的字節偏移量。

  • ptr

    A pointer to an array of bytes. At runtime, this pointer contains the virtual memory address of the string data. The ptr field is not used in Mach-O files.

    指向字節數組的指針。在運行時，此指針包含字符串數據的虛擬內存地址。在mach-o文件中不使用ptr字段。

  Discussion

  Load commands store variable-length data such as library names using the lc_str data structure. Unless otherwise specified, the data consists of a C string.

  The data pointed to is stored just after the load command, and the size is added to the size of the load command. The string should be null terminated; any extra bytes to round up the size should be null. You can also determine the size of the string by subtracting the size of the load command data structure from the cmdsize field of the load command data structure. Load Commands使用lc_str數據結構存儲可變長度的數據，例如庫名稱。除非另有說明，不然數據由C字符串組成。 指向的數據存儲在load command以後，大小將添加到load command的大小中。字符串應以空結尾；要舍入大小的任何額外字節都應爲空。還能夠經過從加載命令數據結構的cmdSize字段中減去加載命令數據結構的大小來肯定字符串的大小。

• dylib

  Defines the data used by the dynamic linker to match a shared library against the files that have linked to it. Used exclusively in the dylib_command (page 32) data structure. Declared in /usr/include/mach-o/loader.h.

  定義動態連接器用於將共享庫與連接到該庫的文件匹配的數據

  /* * Dynamicly linked shared libraries are identified by two things. The * pathname (the name of the library as found for execution), and the * compatibility version number. The pathname must match and the compatibility * number in the user of the library must be greater than or equal to the * library being used. The time stamp is used to record the time a library was * built and copied into user so it can be use to determined if the library used * at runtime is exactly the same as used to built the program. */
  struct dylib {
      union lc_str  name;			/* library's path name */
      uint32_t timestamp;			/* library's build time stamp */
      uint32_t current_version;		/* library's current version number */
      uint32_t compatibility_version;	/* library's compatibility vers number*/
  };
  複製代碼

  Fields

  • name

    A data structure of type lc_str (page 31). Specifies the name of the shared library.

    指定共享庫的名稱 是一個lc_str的結構類型

  • timestamp

    The date and time when the shared library was built.

    建立共享庫的日期和時間。

  • current_version

    The current version of the shared library.

    共享庫的當前版本

  • compatibility_version

    The compatibility version of the shared library.

    共享庫的兼容版本

• dylib_command

  Defines the attributes of the LC_LOAD_DYLIB and LC_ID_DYLIB load commands. Declared in /usr/include/mach-o/loader.h.

  /* * A dynamically linked shared library (filetype == MH_DYLIB in the mach header) * contains a dylib_command (cmd == LC_ID_DYLIB) to identify the library. * An object that uses a dynamically linked shared library also contains a * dylib_command (cmd == LC_LOAD_DYLIB, LC_LOAD_WEAK_DYLIB, or * LC_REEXPORT_DYLIB) for each library it uses. */
  struct dylib_command {
  	uint32_t	cmd;		/* LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB, LC_REEXPORT_DYLIB */
  	uint32_t	cmdsize;	/* includes pathname string */
  	struct dylib dylib;		/* the library identification */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to eitherLC_LOAD_DYLIB, LC_LOAD_WEAK_DYLIB, or LC_ID_DYLIB.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(dylib_command) plus the size of the data pointed to by the name field of the dylib field.

  • dylib

    A data structure of type dylib (page 31). Specifies the attributes of the shared library.

    dylib類型的數據結構。指定共享庫的屬性。

  Discussion

  For each shared library that a file links against, the static linker creates an LC_LOAD_DYLIB command and sets its dylib field to the value of the dylib field of the LC_ID_DYLD load command of the target library. All the LC_LOAD_DYLIB commands together form a list that is ordered according to location in the file, earliest LC_LOAD_DYLIB command first. For two-level namespace files, undefined symbol entries in the symbol table refer to their parent shared libraries by index into this list. The index is called a library ordinal, and it is stored in the n_desc field of the nlist (page 39) data structure. 對於文件連接所針對的每一個共享庫，靜態連接器建立一個LC_LOAD_DYLIB命令，並將其dylib字段設置爲目標庫的LC_ID_DYLD load commands的dylib字段的值。全部LC_LOAD_DYLIB命令一塊兒造成一個列表，該列表根據文件中的位置進行排序，首先是最先的LC_LOAD_DYLIB命令。對於兩級命名空間文件，符號表中未定義的符號項經過索引指向該列表中的父共享庫。索引稱爲庫序號，它存儲在nlist數據結構的n_desc字段中。

  At runtime, the dynamic linker uses the name in the dyld field of the LC_LOAD_DYLIB command to locate the shared library. If it finds the library, the dynamic linker compares the version information of the LC_LOAD_DYLIB load command against the library’s version. For the dynamic linker to successfully link the shared library, the compatibility version of the shared library must be less than or equal to the compatibility version in the LC_LOAD_DYLIB command.

  在運行時，動態連接器使用LC_LOAD_DYLIB命令的dyld字段中的名稱來定位共享庫。若是找到庫，動態連接器將LC_LOAD_DYLIB load commands的版本信息與庫的版本進行比較。要使動態連接器成功連接共享庫，共享庫的兼容版本必須小於或等於LC_LOAD_DYLIB命令中的兼容版本。

  The dynamic linker uses the timestamp to determine whether it can use the prebinding information. The current version is returned by the function NSVersionOfRunTimeLibrary to allow you to determine the version of the library your program is using.

  動態連接器使用時間戳來肯定是否可使用預綁定信息。函數NSVersionOfRunTimeLibrary返回當前版本，容許您肯定程序正在使用的庫的版本。

• dylinker_command

  Defines the attributes of the LC_LOAD_DYLINKER and LC_ID_DYLINKER load commands. Declared in /usr/include/mach-o/loader.h.

  /* * A program that uses a dynamic linker contains a dylinker_command to identify * the name of the dynamic linker (LC_LOAD_DYLINKER). And a dynamic linker * contains a dylinker_command to identify the dynamic linker (LC_ID_DYLINKER). * A file can have at most one of these. * This struct is also used for the LC_DYLD_ENVIRONMENT load command and * contains string for dyld to treat like environment variable. */
  struct dylinker_command {
  	uint32_t	cmd;		/* LC_ID_DYLINKER, LC_LOAD_DYLINKER or LC_DYLD_ENVIRONMENT */
  	uint32_t	cmdsize;	/* includes pathname string */
  	union lc_str    name;		/* dynamic linker's path name */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to either LC_ID_DYLINKER or LC_LOAD_DYLINKER.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(dylinker_command), plus the size of the data pointed to by the name field.

  • name

    A data structure of type lc_str (page 31). Specifies the name of the dynamic linker

  Discussion

  Every executable file that is dynamically linked contains a LC_LOAD_DYLINKER command that specifies the name of the dynamic linker that the kernel must load in order to execute the file. The dynamic linker itself specifies its name using the LC_ID_DYLINKER load command.

  每一個動態連接的可執行文件都包含一個LC_LOAD_DYLINKER命令，該命令指定內核爲了執行文件必須加載的動態連接器的名稱。動態連接器自己使用LC_ID_DYLINKER load command指定其名稱。

• prebound_dylib_command

  Defines the attributes of the LC_PREBOUND_DYLIB load command. For every library that a prebound executable file links to, the static linker adds one LC_PREBOUND_DYLIB command. Declared in /usr/include/mach-o/loader.h.

  /* * A program (filetype == MH_EXECUTE) that is * prebound to its dynamic libraries has one of these for each library that * the static linker used in prebinding. It contains a bit vector for the * modules in the library. The bits indicate which modules are bound (1) and * which are not (0) from the library. The bit for module 0 is the low bit * of the first byte. So the bit for the Nth module is: * (linked_modules[N/8] >> N%8) & 1 */
  struct prebound_dylib_command {
  	uint32_t	cmd;		/* LC_PREBOUND_DYLIB */
  	uint32_t	cmdsize;	/* includes strings */
  	union lc_str	name;		/* library's path name */
  	uint32_t	nmodules;	/* number of modules in library */
  	union lc_str	linked_modules;	/* bit vector of linked modules */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to LC_PREBOUND_DYLIB.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(prebound_dylib_command) plus the size of the data pointed to by the name and linked_modules fields.

  • name

    A data structure of type lc_str (page 31). Specifies the name of the prebound shared library.

    預綁定共享庫的名稱

  • nmodules

    An integer. Specifies the number of modules the prebound shared library contains. The size of the linked_modules string is (nmodules / 8) + (nmodules % 8).

    一個整數。指定預綁定共享庫包含的模塊數。連接的模塊字符串的大小爲（nmodules/8）+（nmodules%8）

  • linked_modules

    A data structure of type lc_str (page 31). Usually, this data structure defines the offset of a C string; in this usage, it is a variable-length bitset, containing one bit for each module. Each bit represents whether the corresponding module is linked to a module in the current file, 1 for yes, 0 for no. The bit for the first module is the low bit of the first byte

    lc_str類型的數據結構（第31頁）。一般，此數據結構定義C字符串的偏移量；在這種用法中，它是一個可變長度的位集，每一個模塊包含一個位。每一個位表示對應的模塊是否連接到當前文件中的模塊，1表示是，0表示否。第一個模塊的位是第一個字節的低位

• thread_command

  Defines the attributes of theLC_THREAD and LC_UNIXTHREAD load commands. The data of this command is specific to each architecture and appears in thread_status.h, located in the architecture’s directory in /usr/include/mach. Declared in /usr/include/mach-o/loader.h.

  struct thread_command {
  	uint32_t	cmd;		/* LC_THREAD or LC_UNIXTHREAD */
  	uint32_t	cmdsize;	/* total size of this command */
  	/* uint32_t flavor flavor of thread state */
  	/* uint32_t count count of uint32_t's in thread state */
  	/* struct XXX_thread_state state thread state for this flavor */
  	/* ... */
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to LC_THREAD or LC_UNIXTHREAD.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(thread_command)

    plus the size of the flavor and count fields plus the size of the CPU-specific thread state data structure.

  • flavor

    Integer specifying the particular flavor of the thread state data structure. See the thread_status.h file for your target architecture.

    整數，指定線程狀態數據結構的特殊類型。請參閱目標體系結構的thread_status.h文件。

  • count

    Size of the thread state data, in number of 32-bit integers. The thread state data structure must be fully padded to 32-bit alignment.

    線程狀態數據的大小，以32位整數爲單位。線程狀態數據結構必須徹底填充爲32位對齊。

• routines_command

  Defines the attributes of the LC_ROUTINES load command, used in 32-bit architectures. Describes the location of the shared library initialization function, which is a function that the dynamic linker calls before allowing any of the routines in the library to be called. Declared in /usr/include/mach-o/loader.h. See also routines_command_64

  定義32位體系結構中使用的LC_ROUTINES load commands的屬性。描述共享庫初始化函數的位置，該函數是動態連接器在容許調用庫中的任何例程以前調用的函數。在/usr/include/mach-o/loader.h中聲明。另請參見例程命令（第36頁）。

  /* * The routines command contains the address of the dynamic shared library * initialization routine and an index into the module table for the module * that defines the routine. Before any modules are used from the library the * dynamic linker fully binds the module that defines the initialization routine * and then calls it. This gets called before any module initialization * routines (used for C++ static constructors) in the library. */
  struct routines_command { /* for 32-bit architectures */
  	uint32_t	cmd;		/* LC_ROUTINES */
  	uint32_t	cmdsize;	/* total size of this command */
  	uint32_t	init_address;	/* address of initialization routine */
  	uint32_t	init_module;	/* index into the module table that */
  				        /* the init routine is defined in */
  	uint32_t	reserved1;
  	uint32_t	reserved2;
  	uint32_t	reserved3;
  	uint32_t	reserved4;
  	uint32_t	reserved5;
  	uint32_t	reserved6;
  };
  
  /* * The 64-bit routines command. Same use as above. */
  struct routines_command_64 { /* for 64-bit architectures */
  	uint32_t	cmd;		/* LC_ROUTINES_64 */
  	uint32_t	cmdsize;	/* total size of this command */
  	uint64_t	init_address;	/* address of initialization routine */
  	uint64_t	init_module;	/* index into the module table that */
  					/* the init routine is defined in */
  	uint64_t	reserved1;
  	uint64_t	reserved2;
  	uint64_t	reserved3;
  	uint64_t	reserved4;
  	uint64_t	reserved5;
  	uint64_t	reserved6;
  };
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to LC_ROUTINES.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(routines_command).

  • init_address

    An integer specifying the virtual memory address of the initialization function.

    指定初始化函數的虛擬內存地址的整數。

  • init_module

    An integer specifying the index into the module table of the module containing the initialization function.

    一個整數，指定包含初始化函數的模塊的模塊表中的索引。

  • reserved1

    Reserved for future use. Set this field to 0.

    保留以備未來使用。將此字段設置爲0

  • reserved2

    Reserved for future use. Set this field to 0.

  • reserved3

    Reserved for future use. Set this field to 0.

  • reserved4

    Reserved for future use. Set this field to 0.

  • reserved5

    Reserved for future use. Set this field to 0.

  • reserved6

    Reserved for future use. Set this field to 0.

  Discussion

  The static linker adds an LC_ROUTINES command when you specify a shared library initialization function using the -init option (see the ld man page for more information). 使用-init選項指定共享庫初始化函數時，靜態連接器會添加LC_ROUTINES命令（有關詳細信息，請參閱ld手冊頁）。

• sub_framework_command

  Defines the attributes of the LC_SUB_FRAMEWORK load command. Identifies the umbrella framework of which this file is a subframework. Declared in /usr/include/mach-o/loader.h.

  /* * A dynamically linked shared library may be a subframework of an umbrella * framework. If so it will be linked with "-umbrella umbrella_name" where * Where "umbrella_name" is the name of the umbrella framework. A subframework * can only be linked against by its umbrella framework or other subframeworks * that are part of the same umbrella framework. Otherwise the static link * editor produces an error and states to link against the umbrella framework. * The name of the umbrella framework for subframeworks is recorded in the * following structure. */
  struct sub_framework_command {
  	uint32_t	cmd;		/* LC_SUB_FRAMEWORK */
  	uint32_t	cmdsize;	/* includes umbrella string */
  	union lc_str 	umbrella;	/* the umbrella framework name */
  };
  複製代碼

  Fields

  • cmd

  • cmdsize

  • umbrella

    A data structure of type lc_str (page 31). Specifies the name of the umbrella framework of which this file is a member.

• sub_umbrella_command

  Defines the attributes of the LC_SUB_UMBRELLA load command. Identifies the named framework as a subumbrella of this framework. Unlike a subframework, any client may link to a subumbrella. Declared in /usr/include/mach-o/loader.h.

  /* * A dynamically linked shared library may be a sub_umbrella of an umbrella * framework. If so it will be linked with "-sub_umbrella umbrella_name" where * Where "umbrella_name" is the name of the sub_umbrella framework. When * staticly linking when -twolevel_namespace is in effect a twolevel namespace * umbrella framework will only cause its subframeworks and those frameworks * listed as sub_umbrella frameworks to be implicited linked in. Any other * dependent dynamic libraries will not be linked it when -twolevel_namespace * is in effect. The primary library recorded by the static linker when * resolving a symbol in these libraries will be the umbrella framework. * Zero or more sub_umbrella frameworks may be use by an umbrella framework. * The name of a sub_umbrella framework is recorded in the following structure. */
  struct sub_umbrella_command {
  	uint32_t	cmd;		/* LC_SUB_UMBRELLA */
  	uint32_t	cmdsize;	/* includes sub_umbrella string */
  	union lc_str 	sub_umbrella;	/* the sub_umbrella framework name */
  };
  複製代碼

  Fields

  • cmd

  • cmdsize

  • sub_umbrella

    A data structure of type lc_str (page 31). Specifies the name of the umbrella framework of which this file is a member.

• sub_library_command

  Defines the attributes of the LC_SUB_LIBRARY load command. Identifies a sublibrary of this framework and marks this framework as an umbrella framework. Unlike a subframework, any client may link to a sublibrary. Declared in /usr/include/mach-o/loader.h.

  /* * A dynamically linked shared library may be a sub_library of another shared * library. If so it will be linked with "-sub_library library_name" where * Where "library_name" is the name of the sub_library shared library. When * staticly linking when -twolevel_namespace is in effect a twolevel namespace * shared library will only cause its subframeworks and those frameworks * listed as sub_umbrella frameworks and libraries listed as sub_libraries to * be implicited linked in. Any other dependent dynamic libraries will not be * linked it when -twolevel_namespace is in effect. The primary library * recorded by the static linker when resolving a symbol in these libraries * will be the umbrella framework (or dynamic library). Zero or more sub_library * shared libraries may be use by an umbrella framework or (or dynamic library). * The name of a sub_library framework is recorded in the following structure. * For example /usr/lib/libobjc_profile.A.dylib would be recorded as "libobjc". */
  struct sub_library_command {
  	uint32_t	cmd;		/* LC_SUB_LIBRARY */
  	uint32_t	cmdsize;	/* includes sub_library string */
  	union lc_str 	sub_library;	/* the sub_library name */
  };
  複製代碼

• sub_client_command

  Defines the attributes of the LC_SUB_CLIENT load command. Specifies the name of a file that is allowed to link to this subframework. This file would otherwise be required to link to the umbrella framework of which this file is a component. Declared in /usr/include/mach-o/loader.h.

  /* * For dynamically linked shared libraries that are subframework of an umbrella * framework they can allow clients other than the umbrella framework or other * subframeworks in the same umbrella framework. To do this the subframework * is built with "-allowable_client client_name" and an LC_SUB_CLIENT load * command is created for each -allowable_client flag. The client_name is * usually a framework name. It can also be a name used for bundles clients * where the bundle is built with "-client_name client_name". */
  struct sub_client_command {
  	uint32_t	cmd;		/* LC_SUB_CLIENT */
  	uint32_t	cmdsize;	/* includes client string */
  	union lc_str 	client;		/* the client name */
  };
  複製代碼

  Special Considerations

  The ld tool generates a sub_client_command load command in the built product if you pass the option -allowable_client , where is the install name of a framework or the client name of a bundle. See the ld man page, specifically about the options -allowable_client and -client_name, for more information.

  若是傳遞選項-allowable_client，其中是框架的安裝名稱或捆綁包的客戶端名稱，則ld工具會在生成的產品中生成一個sub_client_command load commands。有關詳細信息，請參閱ld手冊頁，特別是關於選項-容許的客戶機和-客戶機名稱。

Symbol Table and Related Data Structures

Two load commands, LC_SYMTAB and LC_DYSYMTAB, describe the size and location of the symbol tables, along with additional metadata. The other data structures listed in this section represent the symbol tables themselves.

兩個加載命令LC_SYMTAB和LC_DYSYMTAB描述了符號表的大小和位置以及其餘元數據。本節中列出的其餘數據結構表示符號表自己。

• symtab_command

  Defines the attributes of theLC_SYMTAB load command. Describes the size and location of the symbol table data structures. Declared in /usr/include/mach-o/loader.h.

  定義lc_symtab load commands的屬性。描述符號表數據結構的大小和位置。在/usr/include/mach-o/loader.h中聲明。

  /* * The symtab_command contains the offsets and sizes of the link-edit 4.3BSD * "stab" style symbol table information as described in the header files * <nlist.h> and <stab.h>. */
  struct symtab_command {
  	uint32_t	cmd;		/* LC_SYMTAB */
  	uint32_t	cmdsize;	/* sizeof(struct symtab_command) */
  	uint32_t	symoff;		/* symbol table offset */
  	uint32_t	nsyms;		/* number of symbol table entries */
  	uint32_t	stroff;		/* string table offset */
  	uint32_t	strsize;	/* string table size in bytes */
  };
  複製代碼

  Fields

  • cmd

  • cmdsize

  • symoff

    An integer containing the byte offset from the start of the file to the location of the symbol table entries. The symbol table is an array of nlist (page 39) data structures.

    包含從文件開始到符號表項位置的字節偏移量的整數。符號表是一個由nlist(第39頁)數據結構組成的數組。

  • nsyms

    An integer indicating the number of entries in the symbol table.

    符號表中條目數

  • stroff

    An integer containing the byte offset from the start of the image to the location of the string table.

    包含從圖像開始到字符串表位置的字節偏移量。

  • strsize

    An integer indicating the size (in bytes) of the string table.

    表示字符串表的大小（字節）。

  Discussion

  LC_SYMTAB should exist in both statically linked and dynamically linked file types.

  LC_SYMTAB應該同時存在於靜態連接和動態連接的文件類型中。

• nlist

  Describes an entry in the symbol table for 32-bit architectures. Declared in /usr/include/mach-o/nlist.h. See also nlist_64

  struct nlist {
  	union {
  #ifndef __LP64__
  		char *n_name;	/* for use when in-core */
  #endif
  		uint32_t n_strx;	/* index into the string table */
  	} n_un;
  	uint8_t n_type;		/* type flag, see below */
  	uint8_t n_sect;		/* section number or NO_SECT */
  	int16_t n_desc;		/* see <mach-o/stab.h> */
  	uint32_t n_value;	/* value of this symbol (or stab offset) */
  };
  
  /* * This is the symbol table entry structure for 64-bit architectures. */
  struct nlist_64 {
      union {
          uint32_t  n_strx; /* index into the string table */
      } n_un;
      uint8_t n_type;        /* type flag, see below */
      uint8_t n_sect;        /* section number or NO_SECT */
      uint16_t n_desc;       /* see <mach-o/stab.h> */
      uint64_t n_value;      /* value of this symbol (or stab offset) */
  };
  複製代碼

  Fields

  • n_un

    A union that holds an index into the string table, n_strx. To specify an empty string (""), set this value to 0. The n_name field is not used in Mach-O files.

    共用體保存着在string table中的index，n_strx。若要指定空字符串（「」），請將此值設置爲0。mach-o文件中不使用n_name字段。

  • n_type

    A byte value consisting of data accessed using four bit masks:

    一個字節值，由使用四位掩碼訪問的數據組成：

    /* * The n_type field really contains four fields: * unsigned char N_STAB:3, * N_PEXT:1, * N_TYPE:3, * N_EXT:1; * which are used via the following masks. */
    #define N_STAB 0xe0 /* if any of these bits set, a symbolic debugging entry */
    #define N_PEXT 0x10 /* private external symbol bit */
    #define N_TYPE 0x0e /* mask for the type bits */
    #define N_EXT 0x01 /* external symbol bit, set for external symbols */
    
    /* * Only symbolic debugging entries have some of the N_STAB bits set and if any * of these bits are set then it is a symbolic debugging entry (a stab). In * which case then the values of the n_type field (the entire field) are given * in <mach-o/stab.h> */
    
    /* * Values for N_TYPE bits of the n_type field. */
    #define N_UNDF 0x0 /* undefined, n_sect == NO_SECT */
    #define N_ABS 0x2 /* absolute, n_sect == NO_SECT */
    #define N_SECT 0xe /* defined in section number n_sect */
    #define N_PBUD 0xc /* prebound undefined (defined in a dylib) */
    #define N_INDR 0xa /* indirect */
    複製代碼

    • N_STAB (0xe0)—If any of these 3 bits are set, the symbol is a symbolic debugging table (stab) entry. In that case, the entire n_type field is interpreted as a stab value. See /usr/include/mach-o/stab.h for valid stab values.

      若是設置了這3位中的任何一位，則符號是符號調試表（stab）項。在這種狀況下，整個n_type字段被解釋爲stab值。有關有效的stab值，請參見/usr/include/mach-o/stab.h。

    • N_PEXT (0x10)—If this bit is on, this symbol is marked as having limited global scope. When the file is fed to the static linker, it clears the N_EXT bit for each symbol with the N_PEXT bit set. (The ld option -keep_private_externs turns off this behavior.) With Mac OS X GCC, you can use the private_extern function attribute to set this bit.

      若是該位爲開，則該符號被標記爲具備有限的全局範圍。當文件被饋送到靜態連接器時，它會爲每一個設置了n_-pext位的符號清除n_-ext位。（ld選項-keep_private_externs關閉此行爲）使用mac os x gcc，可使用u private_u extern_uu函數屬性設置此位。

    • N_TYPE (0x0e)—These bits define the type of the symbol.

      定義符號的類型

    • N_EXT (0x01)—If this bit is on, this symbol is an external symbol, a symbol that is either defined outside this file or that is defined in this file but can be referenced by other files.

      若是該位爲開，則該符號爲外部符號，即在此文件外部定義的，或在此文件中定義但能夠被其餘文件引用的。

    Values for the N_TYPE field include:

    • N_UNDF (0x0)—The symbol is undefined. Undefined symbols are symbols referenced in this module but defined in a different module. The n_sect field is set to NO_SECT.

      符號未定義。未定義符號是指在此模塊中引用但在其餘模塊中定義的符號。n_sect字段設置爲NO_SECT。

    • N_ABS (0x2)—The symbol is absolute. The linker does not change the value of an absolute symbol. The n_sect field is set to NO_SECT.

      符號是絕對的。連接器不會更改絕對符號的值。n_sect字段設置爲NO_SECT。

    • N_SECT (0xe)—The symbol is defined in the section number given in n_sect.

    • N_PBUD (0xc)—The symbol is undefined and the image is using a prebound value for the symbol. The n_sect field is set to NO_SECT.

    • N_INDR ( 0xa)—The symbol is defined to be the same as another symbol. The n_value field is an index into the string table specifying the name of the other symbol. When that symbol is linked, both this and the other symbol have the same defined type and value.

      該符號被定義爲與另外一個符號相同。n_value字段是字符串表的索引，用於指定另外一個符號的名稱。連接該符號時，此符號和其餘符號都具備相同的定義類型和值。

  • n_sect

    An integer specifying the number of the section that this symbol can be found in, or NO_SECT

    if the symbol is not to be found in any section of this image. The sections are contiguously numbered across segments, starting from 1, according to the order they appear in the LC_SEGMENT load commands.

    一個整數，指定能夠在其中找到該符號的節的數目，或NO_SECT 若是在圖像的任何部分都找不到符號。根據它們在LC_SEGMENT load commands中出現的順序，分段在分段之間連續編號，從1開始。

  • n_desc

    A 16-bit value providing additional information about the nature of this symbol for non-stab symbols. The reference flags can be accessed using the REFERENCE_TYPE mask (0xF) and are defined as follows:

    一個16位值，爲非stab符號提供關於此符號性質的附加信息。可使用REFERENCE_TYPE掩碼(0xF)訪問引用標誌，定義以下:

  • n_value

    An integer that contains the value of the symbol. The format of this value is different for each type of symbol table entry (as specified by the n_type field). For the N_SECT symbol type, n_value is the address of the symbol. See the description of the n_type field for information on other possible values.

    包含符號值的整數。對於每種類型的符號表條目(由n_type字段指定)，此值的格式是不一樣的。對於N_SECT符號類型，n_value是符號的地址。有關其餘可能值的信息，請參見n_type字段的描述。

  Discussion

  Common symbols must be of type N_UNDF and must have the N_EXT bit set. The n_value for a common symbol is the size (in bytes) of the data of the symbol. In C, a common symbol is a variable that is declared but not initialized in this file. Common symbols can appear only in MH_OBJECT Mach-O files.

  公共符號必須是N_UNDF類型的，而且必須設置N_EXT位。公共符號的n_value是符號數據的大小(以字節爲單位)。在C語言中，公共符號是在該文件中聲明但未初始化的變量。通用符號只能出如今MH_OBJECT Mach-O文件中。

• dysymtab_command

  The data structure for the LC_DYSYMTAB load command. It describes the sizes and locations of the parts of the symbol table used for dynamic linking. Declared in /usr/include/mach-o/loader.h.

  struct dysymtab_command {
      uint32_t cmd;	/* LC_DYSYMTAB */
      uint32_t cmdsize;	/* sizeof(struct dysymtab_command) */
  
      /* * The symbols indicated by symoff and nsyms of the LC_SYMTAB load command * are grouped into the following three groups: * local symbols (further grouped by the module they are from) * defined external symbols (further grouped by the module they are from) * undefined symbols * * The local symbols are used only for debugging. The dynamic binding * process may have to use them to indicate to the debugger the local * symbols for a module that is being bound. * * The last two groups are used by the dynamic binding process to do the * binding (indirectly through the module table and the reference symbol * table when this is a dynamically linked shared library file). */
      uint32_t ilocalsym;	/* index to local symbols */
      uint32_t nlocalsym;	/* number of local symbols */
  
      uint32_t iextdefsym;/* index to externally defined symbols */
      uint32_t nextdefsym;/* number of externally defined symbols */
  
      uint32_t iundefsym;	/* index to undefined symbols */
      uint32_t nundefsym;	/* number of undefined symbols */
  
      /* * For the for the dynamic binding process to find which module a symbol * is defined in the table of contents is used (analogous to the ranlib * structure in an archive) which maps defined external symbols to modules * they are defined in. This exists only in a dynamically linked shared * library file. For executable and object modules the defined external * symbols are sorted by name and is use as the table of contents. */
      uint32_t tocoff;	/* file offset to table of contents */
      uint32_t ntoc;	/* number of entries in table of contents */
  
      /* * To support dynamic binding of "modules" (whole object files) the symbol * table must reflect the modules that the file was created from. This is * done by having a module table that has indexes and counts into the merged * tables for each module. The module structure that these two entries * refer to is described below. This exists only in a dynamically linked * shared library file. For executable and object modules the file only * contains one module so everything in the file belongs to the module. */
      uint32_t modtaboff;	/* file offset to module table */
      uint32_t nmodtab;	/* number of module table entries */
  
      /* * To support dynamic module binding the module structure for each module * indicates the external references (defined and undefined) each module * makes. For each module there is an offset and a count into the * reference symbol table for the symbols that the module references. * This exists only in a dynamically linked shared library file. For * executable and object modules the defined external symbols and the * undefined external symbols indicates the external references. */
      uint32_t extrefsymoff;	/* offset to referenced symbol table */
      uint32_t nextrefsyms;	/* number of referenced symbol table entries */
  
      /* * The sections that contain "symbol pointers" and "routine stubs" have * indexes and (implied counts based on the size of the section and fixed * size of the entry) into the "indirect symbol" table for each pointer * and stub. For every section of these two types the index into the * indirect symbol table is stored in the section header in the field * reserved1. An indirect symbol table entry is simply a 32bit index into * the symbol table to the symbol that the pointer or stub is referring to. * The indirect symbol table is ordered to match the entries in the section. */
      uint32_t indirectsymoff; /* file offset to the indirect symbol table */
      uint32_t nindirectsyms;  /* number of indirect symbol table entries */
  
      /* * To support relocating an individual module in a library file quickly the * external relocation entries for each module in the library need to be * accessed efficiently. Since the relocation entries can't be accessed * through the section headers for a library file they are separated into * groups of local and external entries further grouped by module. In this * case the presents of this load command who's extreloff, nextrel, * locreloff and nlocrel fields are non-zero indicates that the relocation * entries of non-merged sections are not referenced through the section * structures (and the reloff and nreloc fields in the section headers are * set to zero). * * Since the relocation entries are not accessed through the section headers * this requires the r_address field to be something other than a section * offset to identify the item to be relocated. In this case r_address is * set to the offset from the vmaddr of the first LC_SEGMENT command. * For MH_SPLIT_SEGS images r_address is set to the the offset from the * vmaddr of the first read-write LC_SEGMENT command. * * The relocation entries are grouped by module and the module table * entries have indexes and counts into them for the group of external * relocation entries for that the module. * * For sections that are merged across modules there must not be any * remaining external relocation entries for them (for merged sections * remaining relocation entries must be local). */
      uint32_t extreloff;	/* offset to external relocation entries */
      uint32_t nextrel;	/* number of external relocation entries */
  
      /* * All the local relocation entries are grouped together (they are not * grouped by their module since they are only used if the object is moved * from it staticly link edited address). */
      uint32_t locreloff;	/* offset to local relocation entries */
      uint32_t nlocrel;	/* number of local relocation entries */
  
  };	
  複製代碼

  Fields

  • cmd

    Common to all load command structures. For this structure, set to LC_DYSYMTAB.

  • cmdsize

    Common to all load command structures. For this structure, set to sizeof(dysymtab_command).

  • ilocalsym

    An integer indicating the index of the first symbol in the group of local symbols.

    一個整數，表示本地符號組中第一個符號的索引

  • nlocalsym

    An integer indicating the total number of symbols in the group of local symbols.

    表示本地符號組中符號總數

  • iextdefsym

    An integer indicating the index of the first symbol in the group of defined external symbols.

    一個整數，表示定義的外部符號組中第一個符號的索引。

  • nextdefsym

    An integer indicating the total number of symbols in the group of defined external symbols.

    一個整數，表示定義的外部符號組中的符號總數。

  • iundefsym

    An integer indicating the index of the first symbol in the group of undefined external symbols.

    一個整數，表示未定義外部符號組中第一個符號的索引。

  • nundefsym

    An integer indicating the total number of symbols in the group of undefined external symbols

    表示未定義外部符號組中符號總數

  • tocoff

    An integer indicating the byte offset from the start of the file to the table of contents data.

    一個整數，表示從文件開始到目錄數據的字節偏移量。

  • ntoc

    An integer indicating the number of entries in the table of contents.

    表示目錄中條目數的整數。

  • modtaboff

    An integer indicating the byte offset from the start of the file to the module table data.

    一個整數，表示從文件開始到模塊表數據的字節偏移量。

  • nmodtab

    An integer indicating the number of entries in the module table.

    表示模塊表中條目數的整數。

  • extrefsymoff

    An integer indicating the byte offset from the start of the file to the external reference table data.

    一個整數，表示從文件開始到外部引用表數據的字節偏移量。

  • nextrefsyms

    An integer indicating the number of entries in the external reference table.

    表示外部引用表中條目數的整數。

  • indirectsymoff

    An integer indicating the byte offset from the start of the file to the indirect symbol table data.

    一個整數，表示從文件開頭到間接符號表數據的字節偏移量。

  • nindirectsyms

    An integer indicating the number of entries in the indirect symbol table.

    指示間接符號表中條目數的整數。

  • extreloff

    An integer indicating the byte offset from the start of the file to the external relocation table data.

    一個整數，表示從文件開始到外部重定位表數據的字節偏移量

  • nextrel

    An integer indicating the number of entries in the external relocation table.

    一個整數，指示外部從新定位表中的條目數

  • locreloff

    An integer indicating the byte offset from the start of the file to the local relocation table data.

    一個整數，表示從文件開始到本地重定位表數據的字節偏移量

  • nlocrel

    An integer indicating the number of entries in the local relocation table.

    一個整數，指示本地從新定位表中的條目數

  Discussion

  The LC_DYSYMTAB load command contains a set of indexes into the symbol table and a set of file offsets that define the location of several other tables. Fields for tables not used in the file should be set to 0. These tables are described in 「Dynamic Code Generation」 in Mach-O Programming Topics. LC_DYSYMTAB load command包含符號表中的一組索引和一組文件偏移量，它們定義了其餘幾個表的位置。文件中未使用的表的字段應設置爲0。這些表在Mach-O Programming Topics.中的「Dynamic Code Generation」中進行了描述。

• dylib_table_of_contents

  Describes an entry in the table of contents of a dynamic shared library. Declared in /usr/include/mach-o/loader.h.

  /* a table of contents entry */
  struct dylib_table_of_contents {
      uint32_t symbol_index;	/* the defined external symbol (index into the symbol table) */
      uint32_t module_index;	/* index into the module table this symbol is defined in */
  };	
  複製代碼

  Fields

  • symbol_index

    An index into the symbol table indicating the defined external symbol to which this entry refers.

    符號表中的索引，指示此項所引用的已定義外部符號。

  • module_index

    An index into the module table indicating the module in which this defined external symbol is defined.

    模塊表中的索引，指示在其中定義此定義的外部符號的模塊。

• dylib_module

  Describes a module table entry for a dynamic shared library for 32-bit architectures. Declared in /usr/include/mach-o/loader.h.

  /* a module table entry */
  struct dylib_module {
      uint32_t module_name;	/* the module name (index into string table) */
  
      uint32_t iextdefsym;	/* index into externally defined symbols */
      uint32_t nextdefsym;	/* number of externally defined symbols */
      uint32_t irefsym;		/* index into reference symbol table */
      uint32_t nrefsym;		/* number of reference symbol table entries */
      uint32_t ilocalsym;		/* index into symbols for local symbols */
      uint32_t nlocalsym;		/* number of local symbols */
  
      uint32_t iextrel;		/* index into external relocation entries */
      uint32_t nextrel;		/* number of external relocation entries */
  
      uint32_t iinit_iterm;	/* low 16 bits are the index into the init section, high 16 bits are the index into the term section */
      uint32_t ninit_nterm;	/* low 16 bits are the number of init section entries, high 16 bits are the number of term section entries */
  
      uint32_t			/* for this module address of the start of */
  	objc_module_info_addr;  /* the (__OBJC,__module_info) section */
      uint32_t			/* for this module size of */
  	objc_module_info_size;	/* the (__OBJC,__module_info) section */
  };	
  
  /* a 64-bit module table entry */
  struct dylib_module_64 {
      uint32_t module_name;	/* the module name (index into string table) */
  
      uint32_t iextdefsym;	/* index into externally defined symbols */
      uint32_t nextdefsym;	/* number of externally defined symbols */
      uint32_t irefsym;		/* index into reference symbol table */
      uint32_t nrefsym;		/* number of reference symbol table entries */
      uint32_t ilocalsym;		/* index into symbols for local symbols */
      uint32_t nlocalsym;		/* number of local symbols */
  
      uint32_t iextrel;		/* index into external relocation entries */
      uint32_t nextrel;		/* number of external relocation entries */
  
      uint32_t iinit_iterm;	/* low 16 bits are the index into the init section, high 16 bits are the index into the term section */
      uint32_t ninit_nterm;      /* low 16 bits are the number of init section entries, high 16 bits are the number of term section entries */
  
      uint32_t			/* for this module size of */
          objc_module_info_size;	/* the (__OBJC,__module_info) section */
      uint64_t			/* for this module address of the start of */
          objc_module_info_addr;	/* the (__OBJC,__module_info) section */
  };
  複製代碼

  Fields

  • module_name

    An index to an entry in the string table indicating the name of the module.

    指向字符串表中指示模塊名稱的項的索引。

  • iextdefsym

    The index into the symbol table of the first defined external symbol provided by this module.

    此模塊提供的第一個定義的外部符號的符號表索引。

  • nextdefsym

    The number of defined external symbols provided by this module.

    此模塊提供的已定義外部符號的數目

  • irefsym

    The index into the external reference table of the first entry provided by this module.

    此模塊提供的第一個條目的外部引用表的索引

  • nrefsym

    The number of external reference entries provided by this module.

    此模塊提供的外部引用條目數。

  • ilocalsym

    The index into the symbol table of the first local symbol provided by this module.

    此模塊提供的第一個本地符號的符號表索引。

  • nlocalsym

    The number of local symbols provided by this module.

    此模塊提供的本地符號數。

  • iextrel

    The index into the external relocation table of the first entry provided by this module.

    此模塊提供的第一個條目的外部從新定位表的索引

  • nextrel

    The number of entries in the external relocation table that are provided by this module.

    此模塊提供的外部從新定位表中的條目數。

  • iinit_iterm

    Contains both the index into the module initialization section (the low 16 bits) and the index into the module termination section (the high 16 bits) to the pointers for this module.

    包含指向模塊初始化部分（低16位）的索引和指向此模塊指針的模塊終止部分（高16位）的索引。

  • ninit_nterm

    Contains both the number of pointers in the module initialization (the low 16 bits) and the number of pointers in the module termination section (the high 16 bits) for this module.

    包含模塊初始化中的指針數（低16位）和此模塊的模塊終止部分中的指針數（高16位）。

  • objc_module_info_addr

    The statically linked address of the start of the data for this module in the __module_info section in the __OBJC segment.

    在objc段中的模塊信息部分中，此模塊的數據起始的靜態連接地址。

  • objc_module_info_size

    The number of bytes of data for this module that are used in the __module_info section in the __OBJC segment.

    此模塊在objc段中的模塊信息部分中使用的數據字節數。

• dylib_reference

  Defines the attributes of an external reference table entry for the external reference entries provided by a module in a shared library. Declared in /usr/include/mach-o/loader.h.

  /* * The entries in the reference symbol table are used when loading the module * (both by the static and dynamic link editors) and if the module is unloaded * or replaced. Therefore all external symbols (defined and undefined) are * listed in the module's reference table. The flags describe the type of * reference that is being made. The constants for the flags are defined in * <mach-o/nlist.h> as they are also used for symbol table entries. */
  struct dylib_reference {
      uint32_t isym:24,		/* index into the symbol table */
      		  flags:8;	/* flags to indicate the type of reference */
  };
  複製代碼

  Fields

  • isym

    An index into the symbol table for the symbol being referenced

    符號表中被引用符號的索引

  • flags

    A constant for the type of reference being made. Use the same REFERENCE_FLAG constants as described in the nlist (page 39) structure description.

    引用類型的常量。使用與nlist(第39頁)結構描述中描述的相同的REFERENCE_FLAG常量。

Relocation Data Structures

Relocation is the process of moving symbols to a different address. When the static linker moves a symbol (a function or an item of data) to a different address, it needs to change all the references to that symbol to use the new address. The relocation entries in a Mach-O file contain offsets in the file to addresses that need to be relocated when the contents of the file are relocated. The addresses stored in CPU instructions can be absolute or relative. Each relocation entry specifies the exact format of the address. When creating the intermediate object file, the compiler generates one or more relocation entries for every instruction that contains an address. Because relocation to symbols at fixed addresses, and to relative addresses for position independent references, does not occur at runtime, the static linker typically removes some or all the relocation entries when building the final product.

重定位是將符號移動到另外一個地址的過程。當靜態連接器將符號(函數或數據項)移動到另外一個地址時，須要更改對該符號的全部引用，以使用新地址。Mach-O文件中的重定位條目包含文件中的偏移量，這些偏移量指向當文件內容重定位時須要重定位的地址。CPU指令中存儲的地址能夠是絕對地址，也能夠是相對地址。每一個重定位條目指定地址的確切格式。在建立中間對象文件時，編譯器爲包含地址的每條指令生成一個或多個重定位項。因爲在運行時不會對固定地址的符號和位置獨立引用的相對地址進行重定位，所以靜態連接器一般會在構建最終產品時刪除部分或全部重定位項。

Note: In the Mac OS X x86-64 environment scattered relocations are not used. Compiler-generated code uses mostly external relocations, in which the r_extern bit is set to 1 and the r_symbolnum field contains the symbol-table index of the target label.

注意:在Mac OS X x86-64環境中不使用分散重定位。編譯器生成的代碼主要使用外部重定位，其中r_extern位設置爲1,r_symbolnum字段包含目標標籤的符號表索引。

• relocation_info

  Describes an item in the file that uses an address that needs to be updated when the address is changed. Declared in /usr/include/mach-o/reloc.h.

  描述文件中使用地址的項，該地址在地址更改時須要更新。在/usr/include/mach-o/reloc.h中聲明。

  /* * Format of a relocation entry of a Mach-O file. Modified from the 4.3BSD * format. The modifications from the original format were changing the value * of the r_symbolnum field for "local" (r_extern == 0) relocation entries. * This modification is required to support symbols in an arbitrary number of * sections not just the three sections (text, data and bss) in a 4.3BSD file. * Also the last 4 bits have had the r_type tag added to them. */
  struct relocation_info {
     int32_t	r_address;	/* offset in the section to what is being relocated */
     uint32_t     r_symbolnum:24,	/* symbol index if r_extern == 1 or section ordinal if r_extern == 0 */
  		r_pcrel:1, 	/* was relocated pc relative already */
  		r_length:2,	/* 0=byte, 1=word, 2=long, 3=quad */
  		r_extern:1,	/* does not include value of sym referenced */
  		r_type:4;	/* if not 0, machine specific relocation type */
  };
  複製代碼

  Fields

  • r_address

    In MH_OBJECT files, this is an offset from the start of the section to the item containing the address requiring relocation. If the high bit of this field is set (which you can check using the R_SCATTERED bit mask), the relocation_info structure is actually a scattered_relocation_info (page 52) structure.

    In images used by the dynamic linker, this is an offset from the virtual memory address of the data of the first segment_command (page 20) that appears in the file (not necessarily the one with the lowest address). For images with the MH_SPLIT_SEGS flag set, this is an offset from the virtual memory address of data of the first read/write segment_command (page 20).

    在MH_OBJECT文件中，這是從節的開始到包含須要從新定位的地址的項的偏移量。若是設置了該字段的高位(可使用r_scatter位掩碼檢查)，則relocation_info結構其實是scattered_relocation_info(第52頁)結構。 在動態連接器使用的圖像中，這是與文件中出現的第一個segment_command(第20頁)的數據的虛擬內存地址的偏移量(不必定是地址最低的那個)。對於設置了MH_SPLIT_SEGS標誌的圖像，這是第一個讀/寫段_command(第20頁)數據的虛擬內存地址的偏移量。

  • r_symbolnum

    Indicates either an index into the symbol table (when the r_extern field is set to 1) or a section number (when the r_extern field is set to 0). As previously mentioned, sections are ordered from 1 to 255 in the order in which they appear in the LC_SEGMENT load commands. This field is set to R_ABS for relocation entries for absolute symbols, which need no relocation.

    表示符號表中的索引(當r_extern字段設置爲1時)或節號(當r_extern字段設置爲0時)。這個字段被設置爲R_ABS，用於絕對符號的從新定位條目，絕對符號不須要從新定位。

  • r_pcrel

    Indicates whether the item containing the address to be relocated is part of a CPU instruction that uses PC-relative addressing.

    For addresses contained in PC-relative instructions, the CPU adds the address of the instruction to the address contained in the instruction.

    指示包含要從新定位的地址的項是否屬於使用pc相對尋址的CPU指令的一部分。 對於pc相關指令中包含的地址，CPU將指令的地址添加到指令中包含的地址中。

  • r_length

    Indicates the length of the item containing the address to be relocated. The following table lists r_length values and the corresponding address length.

    指示包含要從新定位的地址的項的長度。下表列出了r_length值和相應的地址長度。

    Value	Address length
    0	1 byte
    1	2 bytes
    2	4 bytes
    3	4 bytes. See description for the PPC_RELOC_BR14 r_type in scattered_relocation_info (page 52).

  • r_extern

    Indicates whether the r_symbolnum field is an index into the symbol table (1) or a section number (0).

    指示r_symbolnum字段是符號表(1)的索引仍是節號(0)的索引。

  • r_type

• scattered_relocation_info

  Describes an item in the file—using a nonzero constant in its relocatable expression or two addresses in its relocatable expression—that needs to be updated if the addresses that it uses are changed. This information is needed to reconstruct the addresses that make up the relocatable expression’s value in order to change the addresses independently of each other. Declared in /usr/include/mach-o/reloc.h.

  在可重定位表達式中使用非零常量或在可重定位表達式中使用兩個地址來描述文件中的項——若是使用的地址發生更改，則須要更新這些常量。須要此信息來重構構成可重定位表達式值的地址，以便獨立地更改地址。中聲明/usr/include/mach-o/reloc.h.

  struct scattered_relocation_info {
  #ifdef __BIG_ENDIAN__
     uint32_t	r_scattered:1,	/* 1=scattered, 0=non-scattered (see above) */
  		r_pcrel:1, 	/* was relocated pc relative already */
  		r_length:2,	/* 0=byte, 1=word, 2=long, 3=quad */
  		r_type:4,	/* if not 0, machine specific relocation type */
     		r_address:24;	/* offset in the section to what is being relocated */
     int32_t	r_value;	/* the value the item to be relocated is refering to (without any offset added) */
  #endif /* __BIG_ENDIAN__ */
  #ifdef __LITTLE_ENDIAN__
     uint32_t
     		r_address:24,	/* offset in the section to what is being relocated */
  		r_type:4,	/* if not 0, machine specific relocation type */
  		r_length:2,	/* 0=byte, 1=word, 2=long, 3=quad */
  		r_pcrel:1, 	/* was relocated pc relative already */
  		r_scattered:1;	/* 1=scattered, 0=non-scattered (see above) */
     int32_t	r_value;	/* the value the item to be relocated is refering to (without any offset added) */
  #endif /* __LITTLE_ENDIAN__ */
  };
  複製代碼

  Fields

  • r_scattered

    If this bit is 0, this structure is actually a relocation_info (page 49) structure.

    若是這個位是0，那麼這個結構其實是一個relocation_info(第49頁)結構。

  • r_address

    In MH_OBJECT files, this is an offset from the start of the section to the item containing the address requiring relocation. If the high bit of this field is clear (which you can check using the R_SCATTERED bit mask), this structure is actually a relocation_info (page 49) structure.

    In images used by the dynamic linker, this is an offset from the virtual memory address of the data of the first segment_command (page 20) that appears in the file (not necessarily the one with the lowest address). For images with the MH_SPLIT_SEGS flag set, this is an offset from the virtual memory address of data of the first read/write segment_command (page 20).

    Since this field is only 24 bits long, the offset in this field can never be larger than 0x00FFFFFF, thus limiting the size of the relocatable contents of this image to 16 megabytes.

    在MH_OBJECT文件中，這是從節的開始到包含須要從新定位的地址的項的偏移量。若是這個字段的高位是清除的(可使用r_scatter位掩碼檢查)，那麼這個結構其實是一個relocation_info(第49頁)結構。 在動態連接器使用的圖像中，這是與文件中出現的第一個segment_command(第20頁)的數據的虛擬內存地址的偏移量(不必定是地址最低的那個)。對於設置了MH_SPLIT_SEGS標誌的圖像，這是第一個讀/寫段_command(第20頁)數據的虛擬內存地址的偏移量。 因爲該字段只有24位長，所以該字段中的偏移量永遠不能大於0x00FFFFFF，從而將此圖像的可重定位內容的大小限制爲16 mb。

  • r_pcrel

    Indicates whether the item containing the address to be relocated is part of a CPU instruction that uses PC-relative addressing.

    For addresses contained in PC-relative instructions, the CPU adds the address of the instruction to the address contained in the instruction.

    指示包含要從新定位的地址的項是否屬於使用pc相對尋址的CPU指令的一部分。 對於pc相關指令中包含的地址，CPU將指令的地址添加到指令中包含的地址中。

  • r_length

    Indicates the length of the item containing the address to be relocated. A value of 0 indicates a single byte; a value of 1 indicates a 2-byte address, and a value of 2 indicates a 4-byte address.

    指示包含要從新定位的地址的項的長度。值爲0表示單個字節;值1表示2字節地址，值2表示4字節地址。

  • r_type

    Indicates the type of relocation to be performed. Possible values for this field are shared between this structure and the relocation_info data structure; see the description of the r_type field in the relocation_info (page 49) data structure for more details.

    指示要執行的重定位類型。這個字段的可能值在這個結構和relocation_info數據結構之間共享;有關詳細信息，請參閱relocation_info(第49頁)數據結構中r_type字段的描述。

  • r_value

    The address of the relocatable expression for the item in the file that needs to be updated if the address is changed. For relocatable expressions with the difference of two section addresses, the address from which to subtract (in mathematical terms, the minuend) is contained in the first relocation entry and the address to subtract (the subtrahend) is contained in the second relocation entry.

    若是地址更改，則須要更新文件中項的可重定位表達式的地址。對於兩個節地址不一樣的可重定位表達式，要減去的地址(數學術語爲被減數)包含在第一個重定位項中，要減去的地址(減數)包含在第二個重定位項中。

  Discussion

  Mach-O relocation data structures support two types of relocatable expressions in machine code and data:

  Mach-O重定位數據結構支持兩種類型的可重定位表達式:

  • Symbol address + constant. The most typical form of relocation is referencing a symbol’s address with no constant added. In this case, the value of the constant expression is 0.

    最典型的重定位形式是引用沒有添加常量的符號地址。在本例中，常量表達式的值爲0。

  • Address of section y – address of section x + constant. The section difference form of relocation. This form of relocation supports position-independent code.

    節差形式的移位。這種形式的從新定位支持與位置無關的代碼。

Static Archive Libraries

This section describes the file format used for static archive libraries. Mac OS X uses a format derived from the original BSD static archive library format, with a few minor additions. See the discussion for the ranlib data structure for more information.

本節描述用於靜態存檔庫的文件格式。Mac OS X使用的格式是從原始的BSD靜態存檔庫格式派生出來的，只添加了一些小功能。有關更多信息，請參閱ranlib數據結構的討論。

• ranlib

  Defines the attributes of a static archive library symbol table entry. Declared in /usr/include/mach-o/ranlib.h.

  /* * Structure of the __.SYMDEF table of contents for an archive. * __.SYMDEF begins with a uint32_t giving the size in bytes of the ranlib * structures which immediately follow, and then continues with a string * table consisting of a uint32_t giving the number of bytes of strings which * follow and then the strings themselves. The ran_strx fields index the * string table whose first byte is numbered 0. */
  struct ranlib {
      union {
  	uint32_t	ran_strx;	/* string table index of */
  #ifndef __LP64__
  	char		*ran_name;	/* symbol defined by */
  #endif
      } ran_un;
      uint32_t		ran_off;	/* library member at this offset */
  };
  複製代碼

  Fields

  • ran_strx

    The index number (zero-based) of the string in the string table that follows the array of ranlib data structures.

    在ranlib數據結構數組後面的字符串表中字符串的索引號(從零開始)。

  • ran_name

    The byte offset, from the start of the file, at which the symbol name can be found. This field is not used in Mach-O files.

    從文件開始的字節偏移量，在該偏移量處能夠找到符號名。此字段在Mach-O文件中不使用。

  • ran_off

    The byte offset, from the start of the file, at which the header line for the member containing this symbol can be found.

    從文件開始的字節偏移量，在此位置能夠找到包含此符號的成員的頭行。

  Discussion

  A static archive library begins with the file identifier string !, followed by a newline character (ASCII value 0x0A). The file identifier string is followed by a series of member files. Each member consists of a fixed-length header line followed by the file data. The header line is 60 bytes long and is divided into five fixed-length fields, as shown in this example header line:

  靜態存檔庫以文件標識符字符串!開始，後跟一個換行符(ASCII值0x0A)。文件標識符字符串後面跟着一系列成員文件。每一個成員由一個固定長度的頭行和文件數據組成。頭行爲60字節長，分爲5個固定長度的字段，以下例頭行所示:

  grapple.c       999514211   501   20    100644  167       `
  複製代碼

  The last 2 bytes of the header line are a grave accent (`) character (ASCII value 0x60) and a newline character. All header fields are defined in ASCII and padded with spaces to the full length of the field. All fields are defined in decimal notation, except for the file mode field, which is defined in octal. These are the descriptions for each field:

  頭行最後兩個字節是一個重重音(')字符(ASCII值0x60)和一個換行字符。全部頭字段都是用ASCII定義的，並用空格填充到字段的完整長度。全部字段都是用十進制記數法定義的，文件模式字段除外，它是用八進制定義的。如下是每一個領域的描述:

  • The name field (16 bytes) contains the name of the file. If the name is either longer than 16 bytes or contains a space character, the actual name should be written directly after the header line and the name field should contain the string #1/ followed by the length. To keep the archive entries aligned to 8 byte boundaries, the length of the name that follows the #1/ is rounded to 8 bytes and the name that follows the header is padded with null bytes.

    name字段(16字節)包含文件的名稱。若是名稱大於16字節或包含空格字符，則實際名稱應該直接寫在標題行以後，name字段應該包含字符串#1/後跟長度。爲了使歸檔條目對齊到8個字節的邊界，#1/後面的名稱的長度四捨五入爲8個字節，頭部後面的名稱用空字節填充。

  • The modified date field (12 bytes) is taken from the st_time field returned by the stat system call.

    修改後的日期字段(12字節)取自stat系統調用返回的st_time字段。

  • The user ID field (6 bytes) is taken from the st_uid field returned by the stat system call.

    用戶ID字段(6字節)取自stat系統調用返回的st_uid字段。

  • The group ID field (6 bytes) is taken from the st_gid field returned by the stat system call.

    組ID字段(6字節)取自stat系統調用返回的st_gid字段。

  • The file mode field (8 bytes) is taken from the st_mode field returned by the stat system call. This field is written in octal notation.

    文件模式字段(8字節)取自stat系統調用返回的st_mode字段。這個字段用八進制符號表示。

  • The file size field (8 bytes) is taken from the st_size field returned by the stat system call.

    文件大小字段(8字節)取自stat系統調用返回的st_size字段。

  The first member in a static archive library is always the symbol table describing the contents of the rest of the member files. This member is always called either .SYMDEF or .SYMDEF SORTED (note the two leading underscores and the period). The name used depends on the sort order of the symbol table. The older variant—.SYMDEF—contains entries in the same order that they appear in the object files. The newer variant—.SYMDEF SORTED— contains entries in alphabetical order, which allows the static linker to load the symbols faster.

  靜態存檔庫中的第一個成員老是描述其他成員文件內容的符號表。這個成員老是被稱爲__。SYMDEF或__。SYMDEF排序(注意兩個前導下劃線和句號)。使用的名稱取決於符號表的排序順序。__年長的變體。symdef -包含與它們在目標文件中出現的順序相同的條目。__新的變體。按字母順序包含條目，這容許靜態連接器更快地加載符號。

  The __.SYMDEF and .__SORTED SYMDEF archive members contain an array of ranlib data structures preceded by the length in bytes (a long integer, 4 bytes) of the number of items in the array. The array is followed by a string table of null-terminated strings, which are preceded by the length in bytes of the entire string table (again, a 4-byte long integer).

  __。已排序的SYMDEF archive成員包含一個ranlib數據結構數組，前面是數組中項數的字節長度(一個長整數，4個字節)。數組後面是一個以null結尾的字符串字符串表，它的前面是整個字符串表的字節長度(一樣是一個4字節長的整數)。

  The string table is an array of C strings, each terminated by a null byte. The ranlib declarations can be found in /usr/include/mach-o/ranlib.h.

  Special Considerations

  Prior to the advent of libtool, a tool called ranlib was used to generate the symbol table. ranlib has since been integrated into libtool. See the man page for libtool for more information.

  在libtool出現以前，使用了一個名爲ranlib的工具來生成符號表。ranlib已經集成到libtool中。有關更多信息，請參見libtool的手冊頁。

Universal Binaries 32-bit/64-bit PowerPC Binaries

The standard development tools accept as parameters two kinds of binaries:

標準開發工具接受兩種二進制文件做爲參數:

• Object files targeted at one architecture. These include Mach-O files, static libraries, and dynamic libraries.

  目標文件針對一個體繫結構。其中包括Mach-O文件、靜態庫和動態庫。

• Binaries targeted at more than one architecture. These binaries contain compiled code and data for one of these system types:

  針對多個體繫結構的二進制文件。這些二進制文件包含如下系統類型的編譯代碼和數據:

  • PowerPC-based (32-bit and 64-bit) Macintosh computers. Binaries that contain code for both 32-bit and 64-bit PowerPC-based Macintosh computers are are known as PPC/PPC64 binaries.

    基於powerpc(32位和64位)的Macintosh計算機。包含二者代碼的二進制文件 基於32位和64位powerpc的Macintosh計算機被稱爲PPC/PPC64二進制文件。

  • Intel-based and PowerPC-based (32-bit, 64-bit, or both) Macintosh computers. Binaries that contain code for both Intel-based and PowerPC-based Macintosh computers are known as universal binaries.

    基於intel和基於powerpc(32位、64位或二者都有)的Macintosh計算機。二進制文件 包含基於intel和基於powerpc的Macintosh計算機的代碼 通用二進制文件

  Each object file is stored as a continuous set of bytes at an offset from the beginning of the binary. They use a simple archive format to store the two object files with a special header at the beginning of the file to allow the various runtime tools to quickly find the code appropriate for the current architecture.

  每一個目標文件都存儲爲一組連續的字節，以二進制文件開頭的偏移量爲單位。它們使用一種簡單的歸檔格式來存儲這兩個目標文件，並在文件的開頭使用一個特殊的頭，以容許各類運行時工具快速找到適合當前體系結構的代碼。

A binary that contains code for more than one architecture always begins with a fat_header (page 56) data structure, followed by two fat_arch (page 56) data structures and the actual data for the architectures contained in the file. All data in these data structures is stored in big-endian byte order.

包含多個體繫結構代碼的二進制文件老是以fat_header(第56頁)數據結構開始，而後是兩個fat_arch(第56頁)數據結構和文件中包含的體系結構的實際數據。這些數據結構中的全部數據都以大端字節順序存儲。

• fat_header

  Defines the layout of a binary that contains code for more than one architecture. Declared in the header /usr/include/mach-o/fat.h.

  #define FAT_MAGIC 0xcafebabe
  #define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */
  
  struct fat_header {
  	uint32_t	magic;		/* FAT_MAGIC or FAT_MAGIC_64 */
  	uint32_t	nfat_arch;	/* number of structs that follow */
  };
  複製代碼

  Fields

  • magic

    An integer containing the value 0xCAFEBABE in big-endian byte order format. On a big-endian host CPU, this can be validated using the constant FAT_MAGIC; on a little-endian host CPU, it can be validated using the constant FAT_CIGAM.

    包含值0xCAFEBABE的整數，採用大端字節順序格式。在大端主機CPU上，可使用常量FAT_MAGIC驗證這一點;在little-endian主機CPU上，可使用常量FAT_CIGAM驗證它。

  • nfat_arch

    An integer specifying the number of fat_arch (page 56) data structures that follow. This is the number of architectures contained in this binary.

    一個整數，指定後面的fat_arch(第56頁)數據結構的數量。這是這個二進制文件中包含的體系結構的數量。

  Discussion

  The fat_header data structure is placed at the start of a binary that contains code for multiple architectures. Directly following the fat_header data structure is a set of fat_arch (page 56) data structures, one for each architecture included in the binary.

  Regardless of the content this data structure describes, all its fields are stored in big-endian byte order.

  fat_header數據結構位於包含多個體繫結構代碼的二進制文件的開頭。直接跟隨fat_header數據結構的是一組fat_arch(第56頁)數據結構，每一個結構都包含在二進制文件中。 無論這個數據結構描述的內容是什麼，它的全部字段都以大端字節順序存儲。

• fat_arch

  Describes the location within the binary of an object file targeted at a single architecture. Declared in /usr/include/mach-o/fat.h.

  描述以單一架構爲目標的目標文件二進制文件中的位置。

  struct fat_arch {
  	cpu_type_t	cputype;	/* cpu specifier (int) */
  	cpu_subtype_t	cpusubtype;	/* machine specifier (int) */
  	uint32_t	offset;		/* file offset to this object file */
  	uint32_t	size;		/* size of this object file */
  	uint32_t	align;		/* alignment as a power of 2 */
  };
  複製代碼

  Fields

  • cputype

    An enumeration value of type cpu_type_t. Specifies the CPU family.

    類型cpu_type_t的枚舉值。指定CPU族

  • cpusubtype

    An enumeration value of type cpu_subtype_t. Specifies the specific member of the CPU family on which this entry may be used or a constant specifying all members.

    類型cpu_subtype_t的枚舉值。指定可使用此條目的CPU家族的特定成員，或指定全部成員的常量。

  • offset

    Offset to the beginning of the data for this CPU.

    偏移到此CPU的數據開頭。

  • size

    Size of the data for this CPU.

    這個CPU的數據大小。

  • align

    The power of 2 alignment for the offset of the object file for the architecture specified in cputype

    within the binary. This is required to ensure that, if this binary is changed, the contents it retains are correctly aligned for virtual memory paging and other uses.

    對cputype中指定的體系結構的目標文件的偏移量進行2對齊的能力 在二進制。這是爲了確保，若是這個二進制文件被更改，它保留的內容被正確對齊，以用於虛擬內存分頁和其餘用途。

  Discussion

  An array of fat_arch data structures appears directly after the fat_header (page 56) data structure of a binary that contains object files for multiple architectures.

  Regardless of the content this data structure describes, all its fields are stored in big-endian byte order.

  fat_arch數據結構數組直接出如今包含多個體繫結構目標文件的二進制文件的fat_header(第56頁)數據結構以後。 無論這個數據結構描述的內容是什麼，它的全部字段都以大端字節順序存儲。