Menu

- Learn
- Documentation
  - Language Reference
  - Library Reference
  - Command-line Reference
  - Feature Overview
  - Articles
- Downloads
- Packages
- Community
  - Blog
  - Orgs using D
  - Twitter
  - Calendar
  - Forums
  - IRC
  - Wiki
  - GitHub
  - Issues
  - Get involved
  - Contributors
  - Foundation
  - Security Team
  - Donate
  - Sponsors
- Resources
  - Tour
  - Books
  - Tutorials
  - Tools
  - Editors
  - IDEs
  - run.dlang.io
  - Visual D
  - Acknowledgments
  - D Style
  - Glossary
  - Sitemap

Search
Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using a local clone.

# core.sys.darwin.mach.loader

This file describes the format of Mach-O object files.
D header file for mach-o/`loader`.h from the macOS 10.15 SDK.
License:
Boost License 1.0.
Authors:
Jacob Carlborg
Version:
Initial created: Feb 20, 2010-2018

Source core/sys/darwin/mach/loader.d

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.
  const pure nothrow @nogc @property @safe uint `isym`();
  pure nothrow @nogc @property @safe void `isym`(uint `v`);
    Index into the symbol table.
  const pure nothrow @nogc @property @safe uint `flags`();
  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 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.
  const pure nothrow @nogc @property @safe uint `isub_image`();
  pure nothrow @nogc @property @safe void `isub_image`(uint `v`);
    Index into the sub images.
  const pure nothrow @nogc @property @safe uint `itoc`();
  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.

Copyright © 1999-2019 by the D Language Foundation | Page generated by Ddoc on Sun Sep 1 19:48:59 2019