core.sys.darwin.mach.loader

struct mach_header;

The 32-bit mach header appears at the very beginning of the object file for 32-bit architectures.

uint magic;

Mach magic number identifier.

int cputype;

Cpu specifier.

int cpusubtype;

Machine specifier.

uint filetype;

Type of file.

uint ncmds;

Number of load commands.

uint sizeofcmds;

The size of all the load commands.

uint flags;

Flags.

MH_MAGIC

The mach magic number

MH_CIGAM

NXSwapInt(MH_MAGIC)

struct mach_header_64;

The 64-bit mach header appears at the very beginning of object files for 64-bit architectures.

uint magic;

Mach magic number identifier.

int cputype;

Cpu specifier.

int cpusubtype;

Machine specifier.

uint filetype;

Type of file.

uint ncmds;

Number of load commands.

uint sizeofcmds;

The size of all the load commands.

uint flags;

Flags.

uint reserved;

Reserved.

MH_MAGIC_64

The 64-bit mach magic number.

MH_CIGAM_64

NXSwapInt(MH_MAGIC_64).

MH_OBJECT

Relocatable object file.

MH_EXECUTE

Demand paged executable file.

MH_FVMLIB

Fixed VM shared library file.

MH_CORE

Core file.

MH_PRELOAD

Preloaded executable file.

MH_DYLIB

Dynamically bound shared library.

MH_DYLINKER

Dynamic link editor.

MH_BUNDLE

Dynamically bound bundle file.

MH_DYLIB_STUB

Shared library stub for static linking only, no section contents.

MH_DSYM

Companion file with only debug sections.

MH_KEXT_BUNDLE

X86_64 kexts.

MH_NOUNDEFS

The object file has no undefined references.

MH_INCRLINK

The object file is the output of an incremental link against a base file and can't be link edited again.

MH_DYLDLINK

The object file is input for the dynamic linker and can't be statically link edited again.

MH_BINDATLOAD

The object file's undefined references are bound by the dynamic linker when loaded.

MH_PREBOUND

The file has its dynamic undefined references prebound.

MH_SPLIT_SEGS

The file has its read-only and read-write segments split.

MH_LAZY_INIT

The shared library init routine is to be run lazily via catching memory faults to its writeable segments (obsolete).

MH_TWOLEVEL

The image is using two-level name space bindings.

MH_FORCE_FLAT

The executable is forcing all images to use flat name space bindings.

MH_NOMULTIDEFS

This umbrella guarantees no multiple definitions of symbols in its sub-images so the two-level namespace hints can always be used.

MH_NOFIXPREBINDING

Do not have dyld notify the prebinding agent about this executable.

MH_PREBINDABLE

The binary is not prebound but can have its prebinding redone. only used when MH_PREBOUND is not set.

MH_ALLMODSBOUND

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.

MH_SUBSECTIONS_VIA_SYMBOLS

Safe to divide up the sections into sub-sections via symbols for dead code stripping.

MH_CANONICAL

The binary has been canonicalized via the unprebind operation.

MH_WEAK_DEFINES

The final linked image contains external weak symbols.

MH_BINDS_TO_WEAK

The final linked image uses weak symbols.

MH_ALLOW_STACK_EXECUTION

When this bit is set, all stacks in the task will be given stack execution privilege. Only used in MH_EXECUTE filetypes.

MH_ROOT_SAFE

When this bit is set, the binary declares it is safe for use in processes with uid zero.

MH_SETUID_SAFE

When this bit is set, the binary declares it is safe for use in processes when issetugid() is true.

MH_NO_REEXPORTED_DYLIBS

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.

MH_PIE

When this bit is set, the OS will load the main executable at a random address. Only used in MH_EXECUTE filetypes.

MH_DEAD_STRIPPABLE_DYLIB

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..

MH_HAS_TLV_DESCRIPTORS

Contains a section of type S_THREAD_LOCAL_VARIABLES.

MH_NO_HEAP_EXECUTION

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.

MH_APP_EXTENSION_SAFE

The code was linked for use in an application extension..

MH_NLIST_OUTOFSYNC_WITH_DYLDINFO

The external symbols listed in the nlist symbol table do not include all the symbols listed in the dyld info.

MH_SIM_SUPPORT

Allow LC_MIN_VERSION_MACOS and LC_BUILD_VERSION load commands with the platforms macOS, iOSMac, iOSSimulator, tvOSSimulator and watchOSSimulator.

MH_DYLIB_IN_CACHE

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.

struct load_command;

The load commands directly follow the mach_header. The total size of all of the commands is given by the sizeofcmds field in the mach_header. All load commands must have as their first two fields cmd and cmdsize. The cmd field is filled in with a constant for that command type. Each command type has a structure specifically for it. The cmdsize field is the size in bytes of the particular load command structure plus anything that follows it that is a part of the load command (i.e. section structures, strings, etc.). To advance to the next load command the cmdsize can be added to the offset or pointer of the current load command. The cmdsize for 32-bit architectures MUST be a multiple of 4 bytes and for 64-bit architectures MUST be a multiple of 8 bytes (these are forever the maximum alignment of any load commands). The padded bytes must be zero. All tables in the object file must also follow these rules so the file can be memory mapped. Otherwise the pointers to these tables will not work well or at all on some machines. With all padding zeroed like objects will compare byte for byte.

uint cmd;

Type of load command.

uint cmdsize;

Total size of command in bytes.

enum LC_REQ_DYLD;

After MacOS X 10.1 when a new load command is added that is required to be understood by the dynamic linker for the image to execute properly the LC_REQ_DYLD bit will be or'ed into the load command constant. If the dynamic linker sees such a load command it it does not understand will issue a "unknown load command required for execution" error and refuse to use the image. Other load commands without this bit that are not understood will simply be ignored.

LC_SEGMENT

Segment of this file to be mapped.

LC_SYMTAB

Link-edit stab symbol table info.

LC_SYMSEG

Link-edit gdb symbol table info (obsolete).

LC_THREAD

Thread.

LC_UNIXTHREAD

Unix thread (includes a stack).

LC_LOADFVMLIB

Load a specified fixed VM shared library.

LC_IDFVMLIB

Fixed VM shared library identification.

LC_IDENT

Object identification info (obsolete).

LC_FVMFILE

Fixed VM file inclusion (internal use).

LC_PREPAGE

Prepage command (internal use).

LC_DYSYMTAB

Dynamic link-edit symbol table info.

LC_LOAD_DYLIB

Load a dynamically linked shared library.

LC_ID_DYLIB

Dynamically linked shared lib ident.

LC_LOAD_DYLINKER

Load a dynamic linker.

LC_ID_DYLINKER

Dynamic linker identification.

LC_PREBOUND_DYLIB

Modules prebound for a dynamically linked shared library.

LC_ROUTINES

Image routines.

LC_SUB_FRAMEWORK

Sub framework.

LC_SUB_UMBRELLA

Sub umbrella.

LC_SUB_CLIENT

Sub client.

LC_SUB_LIBRARY

Sub library.

LC_TWOLEVEL_HINTS

Two-level namespace lookup hints.

LC_PREBIND_CKSUM

Prebind checksum.

enum LC_LOAD_WEAK_DYLIB;

Load a dynamically linked shared library that is allowed to be missing (all symbols are weak imported).

LC_SEGMENT_64

64-bit segment of this file to be mapped.

LC_ROUTINES_64

64-bit image routines.

LC_UUID

The uuid.

LC_RPATH

Runpath additions.

LC_CODE_SIGNATURE

Local of code signature.

LC_SEGMENT_SPLIT_INFO

Local of info to split segments.

LC_REEXPORT_DYLIB

Load and re-export dylib.

LC_LAZY_LOAD_DYLIB

Delay load of dylib until first use.

LC_ENCRYPTION_INFO

Encrypted segment information.

LC_DYLD_INFO

Compressed dyld information.

LC_DYLD_INFO_ONLY

Compressed dyld information only.

LC_LOAD_UPWARD_DYLIB

Load upward dylib.

LC_VERSION_MIN_MACOSX

Build for MacOSX min OS version.

LC_VERSION_MIN_IPHONEOS

Build for iPhoneOS min OS version.

LC_FUNCTION_STARTS

Compressed table of function start addresses.

LC_DYLD_ENVIRONMENT

String for dyld to treat like environment variable.

LC_MAIN

Replacement for LC_UNIXTHREAD.

LC_DATA_IN_CODE

Table of non-instructions in _text.

LC_SOURCE_VERSION

Source version used to build binary.

LC_DYLIB_CODE_SIGN_DRS

Code signing DRs copied from linked dylibs.

LC_ENCRYPTION_INFO_64

64-bit encrypted segment information.

LC_LINKER_OPTION

Linker options in MH_OBJECT files.

LC_LINKER_OPTIMIZATION_HINT

Optimization hints in MH_OBJECT files.

LC_VERSION_MIN_TVOS

Build for AppleTV min OS version.

LC_VERSION_MIN_WATCHOS

Build for Watch min OS version.

LC_NOTE

Arbitrary data included within a Mach-O file.

LC_BUILD_VERSION

Build for platform min OS version.

LC_DYLD_EXPORTS_TRIE

Used with linkedit_data_command, payload is trie.

LC_DYLD_CHAINED_FIXUPS

Used with linkedit_data_command.

union lc_str;

A variable length string in a load command is represented by an lc_str union. The strings are stored just after the load command structure and the offset is from the start of the load command structure. The size of the string is reflected in the cmdsize field of the load command. Once again any padded bytes to bring the cmdsize field to a multiple of 4 bytes must be zero.

uint offset;

Offset to the string.

char* ptr;

Pointer to the string (only available on non 64 bit platforms).

struct segment_command;

The segment load command indicates that a part of this file is to be mapped into the task's address space. The size of this segment in memory, vmsize, maybe equal to or larger than the amount to map from this file, filesize. The file is mapped starting at fileoff to the beginning of the segment in memory, vmaddr. The rest of the memory of the segment, if any, is allocated zero fill on demand. The segment's maximum virtual memory protection and initial virtual memory protection are specified by the maxprot and initprot fields. If the segment has sections then the section structures directly follow the segment command and their size is reflected in cmdsize.

uint cmd;

LC_SEGMENT.

uint cmdsize;

Includes sizeof section structs.

char[16] segname;

Segment name.

uint vmaddr;

Memory address of this segment.

uint vmsize;

Memory size of this segment.

uint fileoff;

File offset of this segment.

uint filesize;

Amount to map from the file.

int maxprot;

Maximum VM protection.

int initprot;

Initial VM protection.

uint nsects;

Number of sections in segment.

uint flags;

Flags.

SG_HIGHVM

The file contents for this segment is for the high part of the VM space, the low part is zero filled (for stacks in core files).

SG_FVMLIB

This segment is the VM that is allocated by a fixed VM library, for overlap checking in the link editor.

SG_NORELOC

This segment has nothing that was relocated in it and nothing relocated to it, that is it maybe safely replaced without relocation.

SG_PROTECTED_VERSION_1

This segment is protected.

If the segment starts at file offset 0, the first page of the segment is not protected. All other pages of the segment are protected.

SG_READ_ONLY

This segment is made read-only after fixups.

struct section;

A segment is made up of zero or more sections. Non-MH_OBJECT files have all of their segments with the proper sections in each, and padded to the specified segment alignment when produced by the link editor. The first segment of a MH_EXECUTE and MH_FVMLIB format file contains the mach_header and load commands of the object file before its first section. The zero fill sections are always last in their segment (in all formats). This allows the zeroroed segment padding to be mapped into memory where zero fill sections might be. The gigabyte zero fill sections, those with the section type S_GB_ZEROFILL, can only be in a segment with sections of this type. These segments are then placed after all other segments.

The MH_OBJECT format has all of its sections in one segment for compactness. There is no padding to a specified segment boundary and the mach_header and load commands are not part of the segment.

Sections with the same section name, sectname, going into the same segment, segname, are combined by the link editor. The resulting section, is aligned to the maximum alignment of the combined sections and is the new section's alignment. The combined sections are aligned to their original alignment in the combined section. Any padded bytes to get the specified alignment are zeroed.

The format of the relocation entries referenced by the reloff and nreloc fields of the section structure for mach object files is described in the header file .

char[16] sectname;

Name of this section.

char[16] segname;

Segment this section goes in.

uint addr;

Memory address of this section.

uint size;

Size in bytes of this section.

uint offset;

File offset of this section.

uint align_;

Section alignment (power of 2).

uint reloff;

File offset of relocation entries.

uint nreloc;

Number of relocation entries.

uint flags;

Flags (section type and attributes).

uint reserved1;

Reserved (for offset or index).

uint reserved2;

Reserved (for count or sizeof).

struct section_64;

char[16] sectname;

Name of this section.

char[16] segname;

Segment this section goes in.

ulong addr;

Memory address of this section.

ulong size;

Size in bytes of this section.

uint offset;

File offset of this section.

uint align_;

Section alignment (power of 2).

uint reloff;

File offset of relocation entries.

uint nreloc;

Number of relocation entries.

uint flags;

Flags (section type and attributes).

uint reserved1;

Reserved (for offset or index).

uint reserved2;

Reserved (for count or sizeof).

uint reserved3;

Reserved.

SECTION_TYPE

256 section types.

SECTION_ATTRIBUTES

24 section attributes.

S_REGULAR

Regular section.

S_ZEROFILL

Zero fill on demand section.

S_CSTRING_LITERALS

Section with only literal C strings.

S_4BYTE_LITERALS

Section with only 4 byte literals.

S_8BYTE_LITERALS

Section with only 8 byte literals.

S_LITERAL_POINTERS

Section with only pointers to literals.

S_NON_LAZY_SYMBOL_POINTERS

Section with only non-lazy symbol pointers.

For the two types of symbol pointers sections and the symbol stubs section they have indirect symbol table entries. For each of the entries in the section the indirect symbol table entries, in corresponding order in the indirect symbol table, start at the index stored in the reserved1 field of the section structure. Since the indirect symbol table entries correspond to the entries in the section the number of indirect symbol table entries is inferred from the size of the section divided by the size of the entries in the section. For symbol pointers sections the size of the entries in the section is 4 bytes and for symbol stubs sections the byte size of the stubs is stored in the reserved2 field of the section structure.

S_LAZY_SYMBOL_POINTERS

Section with only lazy symbol pointers.

S_SYMBOL_STUBS

Section with only symbol stubs, byte size of stub in the reserved2 field.

S_MOD_INIT_FUNC_POINTERS

Section with only function pointers for initialization.

S_MOD_TERM_FUNC_POINTERS

Section with only function pointers for termination.

S_COALESCED

Section contains symbols that are to be coalesced.

S_GB_ZEROFILL

Zero fill on demand section (that can be larger than 4 gigabytes).

S_INTERPOSING

Section with only pairs of function pointers for interposing.

S_16BYTE_LITERALS

Section with only 16 byte literals.

S_DTRACE_DOF

Section contains DTrace Object Format.

S_LAZY_DYLIB_SYMBOL_POINTERS

Section with only lazy symbol pointers to lazy loaded dylibs.

S_THREAD_LOCAL_REGULAR

Template of initial values for TLVs.

S_THREAD_LOCAL_ZEROFILL

Template of initial values for TLVs.

S_THREAD_LOCAL_VARIABLES

TLV descriptors.

S_THREAD_LOCAL_VARIABLE_POINTERS

Pointers to TLV descriptors.

S_THREAD_LOCAL_INIT_FUNCTION_POINTERS

Functions to call to initialize TLV values.

S_INIT_FUNC_OFFSETS

32-bit offsets to initializers.

SECTION_ATTRIBUTES_USR

User setable attributes.

S_ATTR_PURE_INSTRUCTIONS

Section contains only true machine instructions.

S_ATTR_NO_TOC

Section contains coalesced symbols that are not to be in a ranlib table of contents.

S_ATTR_STRIP_STATIC_SYMS

Ok to strip static symbols in this section in files with the MH_DYLDLINK flag.

S_ATTR_NO_DEAD_STRIP

No dead stripping.

S_ATTR_LIVE_SUPPORT

Blocks are live if they reference live blocks.

S_ATTR_SELF_MODIFYING_CODE

Used with i386 code stubs written on by dyld.

S_ATTR_DEBUG

A debug section.

If a segment contains any sections marked with S_ATTR_DEBUG then all sections in that segment must have this attribute. No section other than a section marked with this attribute may reference the contents of this section. A section with this attribute may contain no symbols and must have a section type S_REGULAR. The static linker will not copy section contents from sections with this attribute into its output file. These sections generally contain DWARF debugging info.

SECTION_ATTRIBUTES_SYS

System setable attributes.

S_ATTR_SOME_INSTRUCTIONS

Section contains some machine instructions.

S_ATTR_EXT_RELOC

Section has external relocation entries.

S_ATTR_LOC_RELOC

Section has local relocation entries.

SEG_PAGEZERO

The pagezero segment which has no protections and catches NULL references for MH_EXECUTE files.

SEG_TEXT

The tradition UNIX text segment.

SECT_TEXT

The real text part of the text section no headers, and no padding.

SECT_FVMLIB_INIT0

The fvmlib initialization section.

SECT_FVMLIB_INIT1

The section following the fvmlib initialization section.

SEG_DATA

The tradition UNIX data segment.

SECT_DATA

The real initialized data section no padding, no bss overlap.

SECT_BSS

The real uninitialized data section no padding.

SECT_COMMON

The section common symbols are allocated in by the link editor.

SEG_OBJC

Objective-C runtime segment.

SECT_OBJC_SYMBOLS

Symbol table.

SECT_OBJC_MODULES

Module information.

SECT_OBJC_STRINGS

String table.

SECT_OBJC_REFS

String table.

SEG_ICON

The icon segment.

SECT_ICON_HEADER

The icon headers.

SECT_ICON_TIFF

The icons in tiff format.

SEG_LINKEDIT

The segment containing all structs created and maintained by the link editor. Created with -seglinkedit option to ld(1) for MH_EXECUTE and FVMLIB file types only.

SEG_UNIXSTACK

The unix stack segment.

SEG_IMPORT

The segment for the self (dyld) modifing code stubs that has read, write and execute permissions.

struct fvmlib;

Fixed virtual memory shared libraries are identified by two things. The target pathname (the name of the library as found for execution), and the minor version number. The address of where the headers are loaded is in header_addr. (THIS IS OBSOLETE and no longer supported).

lc_str name;

Library's target pathname.

uint minor_version;

Library's minor version number.

uint header_addr;

Library's header address.

struct fvmlib_command;

A fixed virtual shared library (filetype == MH_FVMLIB in the mach header) contains a fvmlib_command (cmd == LC_IDFVMLIB) to identify the library. An object that uses a fixed virtual shared library also contains a fvmlib_command (cmd == LC_LOADFVMLIB) for each library it uses. (THIS IS OBSOLETE and no longer supported).

uint cmd;

LC_IDFVMLIB or LC_LOADFVMLIB.

uint cmdsize;

Includes pathname string.

fvmlib fvmlib_;

The library identification.

struct dylib;

Dynamically 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.

lc_str name;

Library's path name.

uint timestamp;

Library's build time stamp.

uint current_version;

Library's current version number.

uint compatibility_version;

Library's compatibility version number.

struct dylib_command;

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.

uint cmd;

LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB, LC_REEXPORT_DYLIB.

uint cmdsize;

Includes pathname string.

dylib dylib_;

The library identification.

struct sub_framework_command;

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.

uint cmd;

LC_SUB_FRAMEWORK.

uint cmdsize;

Includes umbrella string.

lc_str umbrella;

The umbrella framework name.

struct sub_client_command;

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".

uint cmd;

LC_SUB_CLIENT.

uint cmdsize;

Includes client string.

lc_str client;

The client name.

struct sub_umbrella_command;

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 "umbrella_name" is the name of the sub_umbrella framework. When statically 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.

uint cmd;

LC_SUB_UMBRELLA.

uint cmdsize;

Includes sub_umbrella string.

lc_str sub_umbrella;

The sub_umbrella framework name.

struct sub_library_command;

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 "library_name" is the name of the sub_library shared library. When statically 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".

uint cmd;

LC_SUB_LIBRARY.

uint cmdsize;

Includes sub_library string.

lc_str sub_library;

The sub_library name.

struct prebound_dylib_command;

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

uint cmd;

LC_PREBOUND_DYLIB.

uint cmdsize;

Includes strings.

lc_str name;

Library's path name.

uint nmodules;

Number of modules in library.

lc_str linked_modules;

Bit vector of linked modules.

struct dylinker_command;

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.

uint cmd;

LC_ID_DYLINKER, LC_LOAD_DYLINKER or LC_DYLD_ENVIRONMENT.

uint cmdsize;

Includes pathname string.

lc_str name;

Dynamic linker's path name.

struct thread_command;

Thread commands contain machine-specific data structures suitable for use in the thread state primitives. The machine specific data structures follow the struct thread_command as follows. Each flavor of machine specific data structure is preceded by an uint32_t constant for the flavor of that data structure, an uint32_t that is the count of uint32_t's of the size of the state data structure and then the state data structure follows. This triple may be repeated for many flavors. The constants for the flavors, counts and state data structure definitions are expected to be in the header file . These machine specific data structures sizes must be multiples of 4 bytes. The cmdsize reflects the total size of the thread_command and all of the sizes of the constants for the flavors, counts and state data structures.

For executable objects that are unix processes there will be one thread_command (cmd == LC_UNIXTHREAD) created for it by the link-editor. This is the same as a LC_THREAD, except that a stack is automatically created (based on the shell's limit for the stack size). Command arguments and environment variables are copied onto that stack.

uint cmd;

LC_THREAD or LC_UNIXTHREAD.

uint cmdsize;

Total size of this command.

struct routines_command;

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.

uint cmd;

LC_ROUTINES.

uint cmdsize;

Total size of this command.

uint init_address;

Address of initialization routine.

uint init_module;

Index into the module table that.

uint reserved1;

uint reserved2;

uint reserved3;

uint reserved4;

uint reserved5;

uint reserved6;

struct routines_command_64;

The 64-bit routines command. Same use as above.

uint cmd;

LC_ROUTINES_64.

uint cmdsize;

Total size of this command.

ulong init_address;

Address of initialization routine.

ulong init_module;

Index into the module table that.

ulong reserved1;

ulong reserved2;

ulong reserved3;

ulong reserved4;

ulong reserved5;

ulong reserved6;

struct symtab_command;

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 and .

uint cmd;

LC_SYMTAB.

uint cmdsize;

Sizeof(struct symtab_command).

uint symoff;

Symbol table offset.

uint nsyms;

Number of symbol table entries.

uint stroff;

String table offset.

uint strsize;

String table size in bytes.

struct dysymtab_command;

This is the second set of the symbolic information which is used to support the data structures for the dynamically link editor.

The original set of symbolic information in the symtab_command which contains the symbol and string tables must also be present when this load command is present. When this load command is present the symbol table is organized into three groups of symbols:

• local symbols (static and debugging symbols) - grouped by module
• defined external symbols - grouped by module (sorted by name if not lib)
• undefined external symbols (sorted by name if MH_BINDATLOAD is not set, and in order the were seen by the static linker if MH_BINDATLOAD is set)

In this load command there are offsets and counts to each of the three groups of symbols.

This load command contains a the offsets and sizes of the following new symbolic information tables:

• table of contents
• module table
• reference symbol table
• indirect symbol table

The first three tables above (the table of contents, module table and reference symbol table) are only present if the file is a dynamically linked shared library. For executable and object modules, which are files containing only one module, the information that would be in these three tables is determined as follows:

• table of contents - the defined external symbols are sorted by name
• module table - the file contains only one module so everything in the file is part of the module.
• reference symbol table - is the defined and undefined external symbols

For dynamically linked shared library files this load command also contains offsets and sizes to the pool of relocation entries for all sections separated into two groups:

• external relocation entries
• local relocation entries

For executable and object modules the relocation entries continue to hang off the section structures.

uint cmd;

LC_DYSYMTAB.

uint cmdsize;

sizeof(struct dysymtab_command).

uint ilocalsym;

Index to local symbols.

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).

uint nlocalsym;

Number of local symbols.

uint iextdefsym;

Index to externally defined symbols.

uint nextdefsym;

Number of externally defined symbols.

uint iundefsym;

Index to undefined symbols.

uint nundefsym;

Number of undefined symbols.

uint tocoff;

File offset to table of contents.

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.

uint ntoc;

Number of entries in table of contents.

uint modtaboff;

File offset to module table.

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.

uint nmodtab;

Number of module table entries.

uint extrefsymoff;

Offset to referenced symbol table.

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.

uint nextrefsyms;

Number of referenced symbol table entries.

uint indirectsymoff;

File offset to the indirect symbol table.

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.

uint nindirectsyms;

Number of indirect symbol table entries.

uint extreloff;

Offset to external relocation 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 offset from thevmaddr 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).

uint nextrel;

Number of external relocation entries.

uint locreloff;

Offset to local 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 statically link edited address).

uint nlocrel;

Number of local relocation entries.

INDIRECT_SYMBOL_LOCAL

INDIRECT_SYMBOL_ABS

struct dylib_table_of_contents;

A table of contents entry.

uint symbol_index;

The defined external symbol (index into the symbol table).

uint module_index;

Index into the module table this symbol is defined in.

struct dylib_module;

A module table entry.

uint module_name;

The module name (index into string table).

uint iextdefsym;

Index into externally defined symbols.

uint nextdefsym;

Number of externally defined symbols.

uint irefsym;

Index into reference symbol table.

uint nrefsym;

Number of reference symbol table entries.

uint ilocalsym;

Index into symbols for local symbols.

uint nlocalsym;

Number of local symbols.

uint iextrel;

Index into external relocation entries.

uint nextrel;

Number of external relocation entries.

uint iinit_iterm;

Low 16 bits are the index into the init section, high 16 bits are the index into the term section.

uint ninit_nterm;

Low 16 bits are the number of init section entries, high 16 bits are the number of term section entries.

uint objc_module_info_addr;

The (_OBJC,_module_info) section.

For this module address of the start of.

uint objc_module_info_size;

The (_OBJC,_module_info) section.

For this module size of.

struct dylib_module_64;

A 64-bit module table entry.

uint module_name;

The module name (index into string table).

uint iextdefsym;

Index into externally defined symbols.

uint nextdefsym;

Number of externally defined symbols.

uint irefsym;

Index into reference symbol table.

uint nrefsym;

Number of reference symbol table entries.

uint ilocalsym;

Index into symbols for local symbols.

uint nlocalsym;

Number of local symbols.

uint iextrel;

Index into external relocation entries.

uint nextrel;

Number of external relocation entries.

uint iinit_iterm;

Low 16 bits are the index into the init section, high 16 bits are the index into the term section.

uint ninit_nterm;

Low 16 bits are the number of init section entries, high 16 bits are the number of term section entries.

uint objc_module_info_size;

The (_OBJC,_module_info) section.

For this module size of.

ulong objc_module_info_addr;

The (_OBJC,_module_info) section.

For this module address of the start of.

struct dylib_reference;

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 as they are also used for symbol table entries.

pure nothrow @nogc @property @safe uint isym() const;

pure nothrow @nogc @property @safe void isym(uint v);

Index into the symbol table.

pure nothrow @nogc @property @safe uint flags() const;

pure nothrow @nogc @property @safe void flags(uint v);

Flags to indicate the type of reference.

struct twolevel_hints_command;

The twolevel_hints_command contains the offset and number of hints in the two-level namespace lookup hints table.

uint cmd;

LC_TWOLEVEL_HINTS.

uint cmdsize;

Sizeof(struct twolevel_hints_command).

uint offset;

Offset to the hint table.

uint nhints;

Number of hints in the hint table.

struct twolevel_hint;

The entries in the two-level namespace lookup hints table are twolevel_hint structs. These provide hints to the dynamic link editor where to start looking for an undefined symbol in a two-level namespace image. The isub_image field is an index into the sub-images (sub-frameworks and sub-umbrellas list) that made up the two-level image that the undefined symbol was found in when it was built by the static link editor. If isub-image is 0 the symbol is expected to be defined in library and not in the sub-images. If isub-image is non-zero it is an index into the array of sub-images for the umbrella with the first index in the sub-images being 1. The array of sub-images is the ordered list of sub-images of the umbrella that would be searched for a symbol that has the umbrella recorded as its primary library. The table of contents index is an index into the library's table of contents. This is used as the starting point of the binary search or a directed linear search.

pure nothrow @nogc @property @safe uint isub_image() const;

pure nothrow @nogc @property @safe void isub_image(uint v);

Index into the sub images.

pure nothrow @nogc @property @safe uint itoc() const;

pure nothrow @nogc @property @safe void itoc(uint v);

Index into the table of contents.

struct prebind_cksum_command;

The prebind_cksum_command contains the value of the original check sum for prebound files or zero. When a prebound file is first created or modified for other than updating its prebinding information the value of the check sum is set to zero. When the file has it prebinding re-done and if the value of the check sum is zero the original check sum is calculated and stored in cksum field of this load command in the output file. If when the prebinding is re-done and the cksum field is non-zero it is left unchanged from the input file.

uint cmd;

LC_PREBIND_CKSUM.

uint cmdsize;

Sizeof(struct prebind_cksum_command).

uint cksum;

The check sum or zero.

struct uuid_command;

The uuid load command contains a single 128-bit unique random number that identifies an object produced by the static link editor.

uint cmd;

LC_UUID.

uint cmdsize;

Sizeof(struct uuid_command).

ubyte[16] uuid;

The 128-bit uuid.

struct rpath_command;

The rpath_command contains a path which at runtime should be added to the current run path used to find @rpath prefixed dylibs.

uint cmd;

LC_RPATH.

uint cmdsize;

Includes string.

lc_str path;

Path to add to run path.

struct linkedit_data_command;

The linkedit_data_command contains the offsets and sizes of a blob of data in the _LINKEDIT segment.

uint cmd;

LC_CODE_SIGNATURE, LC_SEGMENT_SPLIT_INFO, LC_FUNCTION_STARTS, LC_DATA_IN_CODE, LC_DYLIB_CODE_SIGN_DRS, LC_LINKER_OPTIMIZATION_HINT, LC_DYLD_EXPORTS_TRIE or LC_DYLD_CHAINED_FIXUPS.

uint cmdsize;

Sizeof(struct linkedit_data_command).

uint dataoff;

File offset of data in _LINKEDIT segment.

uint datasize;

File size of data in _LINKEDIT segment.

struct encryption_info_command;

The encryption_info_command contains the file offset and size of an of an encrypted segment.

uint cmd;

LC_ENCRYPTION_INFO.

uint cmdsize;

Sizeof(struct encryption_info_command).

uint cryptoff;

File offset of encrypted range.

uint cryptsize;

File size of encrypted range.

uint cryptid;

Which encryption system, 0 means not-encrypted yet.

struct encryption_info_command_64;

The encryption_info_command_64 contains the file offset and size of an of an encrypted segment (for use in x86_64 targets).

uint cmd;

LC_ENCRYPTION_INFO_64.

uint cmdsize;

Sizeof(struct encryption_info_command_64).

uint cryptoff;

File offset of encrypted range.

uint cryptsize;

File size of encrypted range.

uint cryptid;

Which encryption system, 0 means not-encrypted yet.

uint pad;

Padding to make this struct's size a multiple of 8 bytes.

struct version_min_command;

The version_min_command contains the min OS version on which this binary was built to run.

uint cmd;

LC_VERSION_MIN_MACOSX or LC_VERSION_MIN_IPHONEOS or LC_VERSION_MIN_WATCHOS or LC_VERSION_MIN_TVOS.

uint cmdsize;

Sizeof(struct min_version_command).

uint version_;

X.Y.Z is encoded in nibbles xxxx.yy.zz.

uint sdk;

X.Y.Z is encoded in nibbles xxxx.yy.zz.

struct build_version_command;

The build_version_command contains the min OS version on which this binary was built to run for its platform. The list of known platforms and tool values following it.

uint cmd;

LC_BUILD_VERSION.

uint cmdsize;

Sizeof(struct build_version_command) plus ntools sizeof(struct build_tool_version).

uint platform;

Platform.

uint minos;

X.Y.Z is encoded in nibbles xxxx.yy.zz.

uint sdk;

X.Y.Z is encoded in nibbles xxxx.yy.zz.

uint ntools;

Number of tool entries following this.

struct build_tool_version;

uint tool;

Enum for the tool.

uint version_;

Version number of the tool.

PLATFORM_MACOS

PLATFORM_IOS

PLATFORM_TVOS

PLATFORM_WATCHOS

PLATFORM_BRIDGEOS

PLATFORM_UIKITFORMAC

PLATFORM_IOSSIMULATOR

PLATFORM_TVOSSIMULATOR

PLATFORM_WATCHOSSIMULATOR

PLATFORM_DRIVERKIT

TOOL_CLANG

TOOL_SWIFT

TOOL_LD

struct dyld_info_command;

The dyld_info_command contains the file offsets and sizes of the new compressed form of the information dyld needs to load the image. This information is used by dyld on Mac OS X 10.6 and later. All information pointed to by this command is encoded using byte streams, so no endian swapping is needed to interpret it.

uint cmd;

LC_DYLD_INFO or LC_DYLD_INFO_ONLY.

uint cmdsize;

Sizeof(struct dyld_info_command).

uint rebase_off;

File offset to rebase info.

Dyld rebases an image whenever dyld loads it at an address different from its preferred address. The rebase information is a stream of byte sized opcodes whose symbolic names start with REBASE_OPCODE_. Conceptually the rebase information is a table of tuples: The opcodes are a compressed way to encode the table by only encoding when a column changes. In addition simple patterns like "every n'th offset for m times" can be encoded in a few bytes.

uint rebase_size;

Size of rebase info.

uint bind_off;

File offset to binding info.

Dyld binds an image during the loading process, if the image requires any pointers to be initialized to symbols in other images. The bind information is a stream of byte sized opcodes whose symbolic names start with BIND_OPCODE_. Conceptually the bind information is a table of tuples: The opcodes are a compressed way to encode the table by only encoding when a column changes. In addition simple patterns like for runs of pointers initialzed to the same value can be encoded in a few bytes.

uint bind_size;

Size of binding info.

uint weak_bind_off;

File offset to weak binding info.

Some C++ programs require dyld to unique symbols so that all images in the process use the same copy of some code/data. This step is done after binding. The content of the weak_bind info is an opcode stream like the bind_info. But it is sorted alphabetically by symbol name. This enable dyld to walk all images with weak binding information in order and look for collisions. If there are no collisions, dyld does no updating. That means that some fixups are also encoded in the bind_info. For instance, all calls to "operator new" are first bound to libstdc++.dylib using the information in bind_info. Then if some image overrides operator new that is detected when the weak_bind information is processed and the call to operator new is then rebound.

uint weak_bind_size;

Size of weak binding info.

uint lazy_bind_off;

File offset to lazy binding info.

Some uses of external symbols do not need to be bound immediately. Instead they can be lazily bound on first use. The lazy_bind are contains a stream of BIND opcodes to bind all lazy symbols. Normal use is that dyld ignores the lazy_bind section when loading an image. Instead the static linker arranged for the lazy pointer to initially point to a helper function which pushes the offset into the lazy_bind area for the symbol needing to be bound, then jumps to dyld which simply adds the offset to lazy_bind_off to get the information on what to bind.

uint lazy_bind_size;

Size of lazy binding infs.

uint export_off;

File offset to lazy binding info.

The symbols exported by a dylib are encoded in a trie. This is a compact representation that factors out common prefixes. It also reduces LINKEDIT pages in RAM because it encodes all information (name, address, flags) in one small, contiguous range. The export area is a stream of nodes. The first node sequentially is the start node for the trie.

Nodes for a symbol start with a uleb128 that is the length of the exported symbol information for the string so far. If there is no exported symbol, the node starts with a zero byte. If there is exported info, it follows the length.

First is a uleb128 containing flags. Normally, it is followed by a uleb128 encoded offset which is location of the content named by the symbol from the mach_header for the image. If the flags is EXPORT_SYMBOL_FLAGS_REEXPORT, then following the flags is a uleb128 encoded library ordinal, then a zero terminated UTF8 string. If the string is zero length, then the symbol is re-export from the specified dylib with the same name. If the flags is EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER, then following the flags is two uleb128s: the stub offset and the resolver offset. The stub is used by non-lazy pointers. The resolver is used by lazy pointers and must be called to get the actual address to use.

After the optional exported symbol information is a byte of how many edges (0-255) that this node has leaving it, followed by each edge. Each edge is a zero terminated UTF8 of the addition chars in the symbol, followed by a uleb128 offset for the node that edge points to.

uint export_size;

Size of lazy binding infs.

REBASE_TYPE_POINTER

REBASE_TYPE_TEXT_ABSOLUTE32

REBASE_TYPE_TEXT_PCREL32

REBASE_OPCODE_MASK

REBASE_IMMEDIATE_MASK

REBASE_OPCODE_DONE

REBASE_OPCODE_SET_TYPE_IMM

REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB

REBASE_OPCODE_ADD_ADDR_ULEB

REBASE_OPCODE_ADD_ADDR_IMM_SCALED

REBASE_OPCODE_DO_REBASE_IMM_TIMES

REBASE_OPCODE_DO_REBASE_ULEB_TIMES

REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB

REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB

BIND_TYPE_POINTER

BIND_TYPE_TEXT_ABSOLUTE32

BIND_TYPE_TEXT_PCREL32

BIND_SPECIAL_DYLIB_SELF

BIND_SPECIAL_DYLIB_MAIN_EXECUTABLE

BIND_SPECIAL_DYLIB_FLAT_LOOKUP

BIND_SPECIAL_DYLIB_WEAK_LOOKUP

BIND_SYMBOL_FLAGS_WEAK_IMPORT

BIND_SYMBOL_FLAGS_NON_WEAK_DEFINITION

BIND_OPCODE_MASK

BIND_IMMEDIATE_MASK

BIND_OPCODE_DONE

BIND_OPCODE_SET_DYLIB_ORDINAL_IMM

BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB

BIND_OPCODE_SET_DYLIB_SPECIAL_IMM

BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM

BIND_OPCODE_SET_TYPE_IMM

BIND_OPCODE_SET_ADDEND_SLEB

BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB

BIND_OPCODE_ADD_ADDR_ULEB

BIND_OPCODE_DO_BIND

BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB

BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED

BIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB

BIND_OPCODE_THREADED

BIND_SUBOPCODE_THREADED_SET_BIND_ORDINAL_TABLE_SIZE_ULEB

BIND_SUBOPCODE_THREADED_APPLY

EXPORT_SYMBOL_FLAGS_KIND_MASK

EXPORT_SYMBOL_FLAGS_KIND_REGULAR

EXPORT_SYMBOL_FLAGS_KIND_THREAD_LOCAL

EXPORT_SYMBOL_FLAGS_KIND_ABSOLUTE

EXPORT_SYMBOL_FLAGS_WEAK_DEFINITION

EXPORT_SYMBOL_FLAGS_REEXPORT

EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER

struct symseg_command;

The symseg_command contains the offset and size of the GNU style symbol table information as described in the header file . The symbol roots of the symbol segments must also be aligned properly in the file. So the requirement of keeping the offsets aligned to a multiple of a 4 bytes translates to the length field of the symbol roots also being a multiple of a long. Also the padding must again be zeroed. (THIS IS OBSOLETE and no longer supported).

uint cmd;

LC_SYMSEG.

uint cmdsize;

Sizeof(struct symseg_command).

uint offset;

Symbol segment offset.

uint size;

Symbol segment size in bytes.

struct ident_command;

The ident_command contains a free format string table following the ident_command structure. The strings are null terminated and the size of the command is padded out with zero bytes to a multiple of 4 bytes/ (THIS IS OBSOLETE and no longer supported).

uint cmd;

LC_IDENT.

uint cmdsize;

Strings that follow this command.

struct fvmfile_command;

The fvmfile_command contains a reference to a file to be loaded at the specified virtual address. (Presently, this command is reserved for internal use. The kernel ignores this command when loading a program into memory).

uint cmd;

LC_FVMFILE.

uint cmdsize;

Includes pathname string.

lc_str name;

Files pathname.

uint header_addr;

Files virtual address.

struct entry_point_command;

The entry_point_command is a replacement for thread_command. It is used for main executables to specify the location (file offset) of main(). If -stack_size was used at link time, the stacksize field will contain the stack size need for the main thread.

uint cmd;

LC_MAIN only used in MH_EXECUTE filetypes.

uint cmdsize;

24.

ulong entryoff;

File (_TEXT) offset of main().

ulong stacksize;

If not zero, initial stack size.

struct source_version_command;

The source_version_command is an optional load command containing the version of the sources used to build the binary.

uint cmd;

LC_SOURCE_VERSION.

uint cmdsize;

16.

ulong version_;

A.B.C.D.E packed as a24.b10.c10.d10.e10.

struct data_in_code_entry;

The LC_DATA_IN_CODE load commands uses a linkedit_data_command to point to an array of data_in_code_entry entries. Each entry describes a range of data in a code section.

uint offset;

From mach_header to start of data range.

ushort length;

Number of bytes in data range.

ushort kind;

A DICE_KIND_* value.

DICE_KIND_DATA

DICE_KIND_JUMP_TABLE8

DICE_KIND_JUMP_TABLE16

DICE_KIND_JUMP_TABLE32

DICE_KIND_ABS_JUMP_TABLE32

struct tlv_descriptor;

Sections of type S_THREAD_LOCAL_VARIABLES contain an array of tlv_descriptor structures.

void* function(tlv_descriptor*) thunk;

c_ulong key;

c_ulong offset;

struct note_command;

LC_NOTE commands describe a region of arbitrary data included in a Mach-O file. Its initial use is to record extra data in MH_CORE files.

uint cmd;

LC_NOTE.

uint cmdsize;

Sizeof(struct note_command).

char[16] data_owner;

Owner name for this LC_NOTE.

ulong offset;

File offset of this data.

ulong size;

Length of data region.