#include <mach-o/loader.h>
mach-o/loader.h
This file describes the format of mach object files.
structmach_header
The 32-bit mach header appears at the very beginning of the object file for
32-bit architectures.
| uint32_t | magic | mach magic number identifier |
| int32_t | cputype | cpu specifier |
| int32_t | cpusubtype | machine specifier |
| uint32_t | filetype | type of file |
| uint32_t | ncmds | number of load commands |
| uint32_t | sizeofcmds | the size of all the load commands |
| uint32_t | flags | flags |
macroMH_MAGIC
Constant for the magic field of the mach_header (32-bit architectures)
#define MH_MAGIC 0xfeedface
the mach magic number
structmach_header_64
The 64-bit mach header appears at the very beginning of object files for
64-bit architectures.
| uint32_t | magic | mach magic number identifier |
| int32_t | cputype | cpu specifier |
| int32_t | cpusubtype | machine specifier |
| uint32_t | filetype | type of file |
| uint32_t | ncmds | number of load commands |
| uint32_t | sizeofcmds | the size of all the load commands |
| uint32_t | flags | flags |
| uint32_t | reserved | reserved |
macroMH_MAGIC_64
Constant for the magic field of the mach_header_64 (64-bit architectures)
#define MH_MAGIC_64 0xfeedfacf
the 64-bit mach magic number
macroMH_OBJECT
The layout of the file depends on the filetype. For all but the MH_OBJECT
file type the segments are padded out and aligned on a segment alignment
boundary for efficient demand pageing. The MH_EXECUTE, MH_FVMLIB, MH_DYLIB,
MH_DYLINKER and MH_BUNDLE file types also have the headers included as part
of their first segment.
The file type MH_OBJECT is a compact format intended as output of the
assembler and input (and possibly output) of the link editor (the .o
format). All sections are in one unnamed segment with no segment padding.
This format is used as an executable format when the file is so small the
segment padding greatly increases its size.
The file type MH_PRELOAD is an executable format intended for things that
are not executed under the kernel (proms, stand alones, kernels, etc). The
format can be executed under the kernel but may demand paged it and not
preload it before execution.
A core file is in MH_CORE format and can be any in an arbritray legal
Mach-O file.
Constants for the filetype field of the mach_header
#define MH_OBJECT 0x1
relocatable object file
macroMH_DYLIB_STUB
#define MH_DYLIB_STUB 0x9
shared library stub for static
linking only, no section contents
macroMH_FILESET
#define MH_FILESET 0xc
a file composed of other Mach-Os to
be run in the same userspace sharing
a single linkedit.
macroMH_NOUNDEFS
Constants for the flags field of the mach_header
#define MH_NOUNDEFS 0x1
the object file has no undefined
references
macroMH_INCRLINK
#define MH_INCRLINK 0x2
the object file is the output of an
incremental link against a base file
and can't be link edited again
macroMH_DYLDLINK
#define MH_DYLDLINK 0x4
the object file is input for the
dynamic linker and can't be staticly
link edited again
macroMH_BINDATLOAD
#define MH_BINDATLOAD 0x8
the object file's undefined
references are bound by the dynamic
linker when loaded.
macroMH_SPLIT_SEGS
#define MH_SPLIT_SEGS 0x20
the file has its read-only and
read-write segments split
macroMH_LAZY_INIT
#define MH_LAZY_INIT 0x40
the shared library init routine is
to be run lazily via catching memory
faults to its writeable segments
(obsolete)
macroMH_FORCE_FLAT
#define MH_FORCE_FLAT 0x100
the executable is forcing all images
to use flat name space bindings
macroMH_NOMULTIDEFS
#define MH_NOMULTIDEFS 0x200
this umbrella guarantees no multiple
defintions of symbols in its
sub-images so the two-level namespace
hints can always be used.
macroMH_NOFIXPREBINDING
#define MH_NOFIXPREBINDING 0x400
do not have dyld notify the
prebinding agent about this
executable
macroMH_PREBINDABLE
#define MH_PREBINDABLE 0x800
the binary is not prebound but can
have its prebinding redone. only used
when MH_PREBOUND is not set.
macroMH_ALLMODSBOUND
#define MH_ALLMODSBOUND 0x1000
indicates that this binary binds to
all two-level namespace modules of
its dependent libraries. only used
when MH_PREBINDABLE and MH_TWOLEVEL
are both set.
macroMH_SUBSECTIONS_VIA_SYMBOLS
#define MH_SUBSECTIONS_VIA_SYMBOLS 0x2000
safe to divide up the sections into
sub-sections via symbols for dead
code stripping
macroMH_CANONICAL
#define MH_CANONICAL 0x4000
the binary has been canonicalized
via the unprebind operation
macroMH_WEAK_DEFINES
#define MH_WEAK_DEFINES 0x8000
the final linked image contains
external weak symbols
macroMH_ALLOW_STACK_EXECUTION
#define MH_ALLOW_STACK_EXECUTION 0x20000
When this bit is set, all stacks
in the task will be given stack
execution privilege. Only used in
MH_EXECUTE filetypes.
macroMH_ROOT_SAFE
#define MH_ROOT_SAFE 0x40000
When this bit is set, the binary
declares it is safe for use in
processes with uid zero
macroMH_SETUID_SAFE
#define MH_SETUID_SAFE 0x80000
When this bit is set, the binary
declares it is safe for use in
processes when issetugid() is true
macroMH_NO_REEXPORTED_DYLIBS
#define MH_NO_REEXPORTED_DYLIBS 0x100000
When this bit is set on a dylib,
the static linker does not need to
examine dependent dylibs to see
if any are re-exported
macroMH_PIE
#define MH_PIE 0x200000
When this bit is set, the OS will
load the main executable at a
random address. Only used in
MH_EXECUTE filetypes.
macroMH_DEAD_STRIPPABLE_DYLIB
#define MH_DEAD_STRIPPABLE_DYLIB 0x400000
Only for use on dylibs. When
linking against a dylib that
has this bit set, the static linker
will automatically not create a
LC_LOAD_DYLIB load command to the
dylib if no symbols are being
referenced from the dylib.
macroMH_HAS_TLV_DESCRIPTORS
#define MH_HAS_TLV_DESCRIPTORS 0x800000
Contains a section of type
S_THREAD_LOCAL_VARIABLES
macroMH_NO_HEAP_EXECUTION
#define MH_NO_HEAP_EXECUTION 0x1000000
When this bit is set, the OS will
run the main executable with
a non-executable heap even on
platforms (e.g. i386) that don't
require it. Only used in MH_EXECUTE
filetypes.
macroMH_APP_EXTENSION_SAFE
#define MH_APP_EXTENSION_SAFE 0x02000000
The code was linked for use in an
application extension.
macroMH_NLIST_OUTOFSYNC_WITH_DYLDINFO
#define MH_NLIST_OUTOFSYNC_WITH_DYLDINFO 0x04000000
The external symbols
listed in the nlist symbol table do
not include all the symbols listed in
the dyld info.
macroMH_SIM_SUPPORT
#define MH_SIM_SUPPORT 0x08000000
Allow LC_MIN_VERSION_MACOS and
LC_BUILD_VERSION load commands with
the platforms macOS, macCatalyst,
iOSSimulator, tvOSSimulator and
watchOSSimulator.
macroMH_IMPLICIT_PAGEZERO
#define MH_IMPLICIT_PAGEZERO 0x10000000
main executable has no __PAGEZERO
segment. Instead, loader (xnu)
will load program high and block
out all memory below it.
macroMH_DYLIB_IN_CACHE
#define MH_DYLIB_IN_CACHE 0x80000000
Only for use on dylibs. When this bit
is set, the dylib is part of the dyld
shared cache, rather than loose in
the filesystem.
structload_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.
| uint32_t | cmd | type of load command |
| uint32_t | cmdsize | total size of command in bytes |
macroLC_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.
#define LC_REQ_DYLD 0x80000000
macroLC_SEGMENT
Constants for the cmd field of all load commands, the type
#define LC_SEGMENT 0x1
segment of this file to be mapped
macroLC_LOAD_WEAK_DYLIB
load a dynamically linked shared library that is allowed to be missing
(all symbols are weak imported).
#define LC_LOAD_WEAK_DYLIB (0x18 | LC_REQ_DYLD)
macroLC_DYLD_ENVIRONMENT
#define LC_DYLD_ENVIRONMENT 0x27
string for dyld to treat
like environment variable
macroLC_DYLIB_CODE_SIGN_DRS
#define LC_DYLIB_CODE_SIGN_DRS 0x2B
Code signing DRs copied from linked dylibs
macroLC_LINKER_OPTIMIZATION_HINT
#define LC_LINKER_OPTIMIZATION_HINT 0x2E
optimization hints in MH_OBJECT files
macroLC_DYLD_EXPORTS_TRIE
#define LC_DYLD_EXPORTS_TRIE (0x33 | LC_REQ_DYLD)
used with linkedit_data_command, payload is trie
macroLC_DYLD_CHAINED_FIXUPS
#define LC_DYLD_CHAINED_FIXUPS (0x34 | LC_REQ_DYLD)
used with linkedit_data_command
macroLC_FUNCTION_VARIANT_FIXUPS
#define LC_FUNCTION_VARIANT_FIXUPS 0x38
used with linkedit_data_command
unionlc_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.
| uint32_t | offset | offset to the string |
structsegment_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.
| uint32_t | cmd | LC_SEGMENT |
| uint32_t | cmdsize | includes sizeof section structs |
| char[16] | segname | segment name |
| uint32_t | vmaddr | memory address of this segment |
| uint32_t | vmsize | memory size of this segment |
| uint32_t | fileoff | file offset of this segment |
| uint32_t | filesize | amount to map from the file |
| int32_t | maxprot | maximum VM protection |
| int32_t | initprot | initial VM protection |
| uint32_t | nsects | number of sections in segment |
| uint32_t | flags | flags |
structsegment_command_64
The 64-bit segment load command indicates that a part of this file is to be
mapped into a 64-bit task's address space. If the 64-bit segment has
sections then section_64 structures directly follow the 64-bit segment
command and their size is reflected in cmdsize.
| uint32_t | cmd | LC_SEGMENT_64 |
| uint32_t | cmdsize | includes sizeof section_64 structs |
| char[16] | segname | segment name |
| uint64_t | vmaddr | memory address of this segment |
| uint64_t | vmsize | memory size of this segment |
| uint64_t | fileoff | file offset of this segment |
| uint64_t | filesize | amount to map from the file |
| int32_t | maxprot | maximum VM protection |
| int32_t | initprot | initial VM protection |
| uint32_t | nsects | number of sections in segment |
| uint32_t | flags | flags |
macroSG_HIGHVM
Constants for the flags field of the segment_command
#define SG_HIGHVM 0x1
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)
macroSG_FVMLIB
#define SG_FVMLIB 0x2
this segment is the VM that is allocated by
a fixed VM library, for overlap checking in
the link editor
macroSG_NORELOC
#define SG_NORELOC 0x4
this segment has nothing that was relocated
in it and nothing relocated to it, that is
it maybe safely replaced without relocation
macroSG_PROTECTED_VERSION_1
#define SG_PROTECTED_VERSION_1 0x8
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.
structsection
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 zeroed 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 <reloc.h>.
| char[16] | sectname | name of this section |
| char[16] | segname | segment this section goes in |
| uint32_t | addr | memory address of this section |
| uint32_t | size | size in bytes of this section |
| uint32_t | offset | file offset of this section |
| uint32_t | align | section alignment (power of 2) |
| uint32_t | reloff | file offset of relocation entries |
| uint32_t | nreloc | number of relocation entries |
| uint32_t | flags | flags (section type and attributes) |
| uint32_t | reserved1 | reserved (for offset or index) |
| uint32_t | reserved2 | reserved (for count or sizeof) |
structsection_64
| char[16] | sectname | name of this section |
| char[16] | segname | segment this section goes in |
| uint64_t | addr | memory address of this section |
| uint64_t | size | size in bytes of this section |
| uint32_t | offset | file offset of this section |
| uint32_t | align | section alignment (power of 2) |
| uint32_t | reloff | file offset of relocation entries |
| uint32_t | nreloc | number of relocation entries |
| uint32_t | flags | flags (section type and attributes) |
| uint32_t | reserved1 | reserved (for offset or index) |
| uint32_t | reserved2 | reserved (for count or sizeof) |
| uint32_t | reserved3 | reserved |
macroSECTION_TYPE
The flags field of a section structure is separated into two parts a section
type and section attributes. The section types are mutually exclusive (it
can only have one type) but the section attributes are not (it may have more
than one attribute).
#define SECTION_TYPE 0x000000ff
256 section types
macroS_NON_LAZY_SYMBOL_POINTERS
literals
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.
#define S_NON_LAZY_SYMBOL_POINTERS 0x6
section with only non-lazy
symbol pointers
macroS_SYMBOL_STUBS
#define S_SYMBOL_STUBS 0x8
section with only symbol
stubs, byte size of stub in
the reserved2 field
macroS_MOD_INIT_FUNC_POINTERS
#define S_MOD_INIT_FUNC_POINTERS 0x9
section with only function
pointers for initialization
macroS_MOD_TERM_FUNC_POINTERS
#define S_MOD_TERM_FUNC_POINTERS 0xa
section with only function
pointers for termination
macroS_GB_ZEROFILL
#define S_GB_ZEROFILL 0xc
zero fill on demand section
(that can be larger than 4
gigabytes)
macroS_INTERPOSING
#define S_INTERPOSING 0xd
section with only pairs of
function pointers for
interposing
macroS_LAZY_DYLIB_SYMBOL_POINTERS
#define S_LAZY_DYLIB_SYMBOL_POINTERS 0x10
section with only lazy
symbol pointers to lazy
loaded dylibs
macroS_THREAD_LOCAL_REGULAR
Section types to support thread local variables
#define S_THREAD_LOCAL_REGULAR 0x11
template of initial
values for TLVs
macroS_THREAD_LOCAL_VARIABLE_POINTERS
#define S_THREAD_LOCAL_VARIABLE_POINTERS 0x14
pointers to TLV
descriptors
macroS_THREAD_LOCAL_INIT_FUNCTION_POINTERS
#define S_THREAD_LOCAL_INIT_FUNCTION_POINTERS 0x15
functions to call
to initialize TLV
values
macroSECTION_ATTRIBUTES_USR
Constants for the section attributes part of the flags field of a section
structure.
#define SECTION_ATTRIBUTES_USR 0xff000000
User setable attributes
macroS_ATTR_PURE_INSTRUCTIONS
#define S_ATTR_PURE_INSTRUCTIONS 0x80000000
section contains only true
machine instructions
macroS_ATTR_NO_TOC
#define S_ATTR_NO_TOC 0x40000000
section contains coalesced
symbols that are not to be
in a ranlib table of
contents
macroS_ATTR_STRIP_STATIC_SYMS
#define S_ATTR_STRIP_STATIC_SYMS 0x20000000
ok to strip static symbols
in this section in files
with the MH_DYLDLINK flag
macroS_ATTR_LIVE_SUPPORT
#define S_ATTR_LIVE_SUPPORT 0x08000000
blocks are live if they
reference live blocks
macroS_ATTR_SELF_MODIFYING_CODE
#define S_ATTR_SELF_MODIFYING_CODE 0x04000000
Used with i386 code stubs
written on by dyld
macroS_ATTR_DEBUG
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.
#define S_ATTR_DEBUG 0x02000000
a debug section
macroS_ATTR_SOME_INSTRUCTIONS
#define S_ATTR_SOME_INSTRUCTIONS 0x00000400
section contains some
machine instructions
macroSECT_FVMLIB_INIT0
section no headers, and no padding
#define SECT_FVMLIB_INIT0 "__fvmlib_init0"
the fvmlib initialization
structfvmlib
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).
| union lc_str | name | library's target pathname |
| uint32_t | minor_version | library's minor version number |
| uint32_t | header_addr | library's header address |
structfvmlib_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).
| uint32_t | cmd | LC_IDFVMLIB or LC_LOADFVMLIB |
| uint32_t | cmdsize | includes pathname string |
| struct fvmlib | fvmlib | the library identification |
structdylib
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.
| union lc_str | name | library's path name |
| uint32_t | timestamp | library's build time stamp |
| uint32_t | current_version | library's current version number |
| uint32_t | compatibility_version | library's compatibility vers number |
structdylib_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.
| uint32_t | cmd | LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB, LC_REEXPORT_DYLIB |
| uint32_t | cmdsize | includes pathname string |
| struct dylib | dylib | the library identification |
structdylib_use_command
An alternate encoding for: LC_LOAD_DYLIB.
The flags field contains independent flags DYLIB_USE_*
First supported in macOS 15, iOS 18.
| uint32_t | cmd | LC_LOAD_DYLIB or LC_LOAD_WEAK_DYLIB |
| uint32_t | cmdsize | overall size, including path |
| uint32_t | nameoff | == 28, dylibs's path offset |
| uint32_t | marker | == DYLIB_USE_MARKER |
| uint32_t | current_version | dylib's current version number |
| uint32_t | compat_version | dylib's compatibility version number |
| uint32_t | flags | DYLIB_USE_... flags |
macroDYLIB_USE_WEAK_LINK
#define DYLIB_USE_WEAK_LINK 0x01
macroDYLIB_USE_REEXPORT
#define DYLIB_USE_REEXPORT 0x02
macroDYLIB_USE_UPWARD
#define DYLIB_USE_UPWARD 0x04
macroDYLIB_USE_DELAYED_INIT
#define DYLIB_USE_DELAYED_INIT 0x08
macroDYLIB_USE_MARKER
#define DYLIB_USE_MARKER 0x1a741800
structsub_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.
| uint32_t | cmd | LC_SUB_FRAMEWORK |
| uint32_t | cmdsize | includes umbrella string |
| union lc_str | umbrella | the umbrella framework name |
structsub_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".
| uint32_t | cmd | LC_SUB_CLIENT |
| uint32_t | cmdsize | includes client string |
| union lc_str | client | the client name |
structsub_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
Where "umbrella_name" is the name of the sub_umbrella framework. When
staticly linking when -twolevel_namespace is in effect a twolevel namespace
umbrella framework will only cause its subframeworks and those frameworks
listed as sub_umbrella frameworks to be implicited linked in. Any other
dependent dynamic libraries will not be linked it when -twolevel_namespace
is in effect. The primary library recorded by the static linker when
resolving a symbol in these libraries will be the umbrella framework.
Zero or more sub_umbrella frameworks may be use by an umbrella framework.
The name of a sub_umbrella framework is recorded in the following structure.
| uint32_t | cmd | LC_SUB_UMBRELLA |
| uint32_t | cmdsize | includes sub_umbrella string |
| union lc_str | sub_umbrella | the sub_umbrella framework name |
structsub_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
Where "library_name" is the name of the sub_library shared library. When
staticly linking when -twolevel_namespace is in effect a twolevel namespace
shared library will only cause its subframeworks and those frameworks
listed as sub_umbrella frameworks and libraries listed as sub_libraries to
be implicited linked in. Any other dependent dynamic libraries will not be
linked it when -twolevel_namespace is in effect. The primary library
recorded by the static linker when resolving a symbol in these libraries
will be the umbrella framework (or dynamic library). Zero or more sub_library
shared libraries may be use by an umbrella framework or (or dynamic library).
The name of a sub_library framework is recorded in the following structure.
For example /usr/lib/libobjc_profile.A.dylib would be recorded as "libobjc".
| uint32_t | cmd | LC_SUB_LIBRARY |
| uint32_t | cmdsize | includes sub_library string |
| union lc_str | sub_library | the sub_library name |
structprebound_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
| uint32_t | cmd | LC_PREBOUND_DYLIB |
| uint32_t | cmdsize | includes strings |
| union lc_str | name | library's path name |
| uint32_t | nmodules | number of modules in library |
| union lc_str | linked_modules | bit vector of linked modules |
structdylinker_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.
| uint32_t | cmd | LC_ID_DYLINKER, LC_LOAD_DYLINKER or LC_DYLD_ENVIRONMENT |
| uint32_t | cmdsize | includes pathname string |
| union lc_str | name | dynamic linker's path name |
structthread_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 <machine/thread_status.h>.
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.
| uint32_t | cmd | LC_THREAD or LC_UNIXTHREAD |
| uint32_t | cmdsize | total size of this command |
structroutines_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.
| uint32_t | cmd | LC_ROUTINES |
| uint32_t | cmdsize | total size of this command |
| uint32_t | init_address | address of initialization routine |
| uint32_t | init_module | index into the module table that |
| uint32_t | reserved1 | the init routine is defined in |
| uint32_t | reserved2 | |
| uint32_t | reserved3 | |
| uint32_t | reserved4 | |
| uint32_t | reserved5 | |
| uint32_t | reserved6 |
structroutines_command_64
The 64-bit routines command. Same use as above.
| uint32_t | cmd | LC_ROUTINES_64 |
| uint32_t | cmdsize | total size of this command |
| uint64_t | init_address | address of initialization routine |
| uint64_t | init_module | index into the module table that |
| uint64_t | reserved1 | the init routine is defined in |
| uint64_t | reserved2 | |
| uint64_t | reserved3 | |
| uint64_t | reserved4 | |
| uint64_t | reserved5 | |
| uint64_t | reserved6 |
structsymtab_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
<nlist.h> and <stab.h>.
| uint32_t | cmd | LC_SYMTAB |
| uint32_t | cmdsize | sizeof(struct symtab_command) |
| uint32_t | symoff | symbol table offset |
| uint32_t | nsyms | number of symbol table entries |
| uint32_t | stroff | string table offset |
| uint32_t | strsize | string table size in bytes |
structdysymtab_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.
| uint32_t | cmd | LC_DYSYMTAB |
| uint32_t | cmdsize | sizeof(struct dysymtab_command) |
| uint32_t | ilocalsym | 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). index to local symbols |
| uint32_t | nlocalsym | number of local symbols |
| uint32_t | iextdefsym | index to externally defined symbols |
| uint32_t | nextdefsym | number of externally defined symbols |
| uint32_t | iundefsym | index to undefined symbols |
| uint32_t | nundefsym | number of undefined symbols |
| uint32_t | tocoff | 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. file offset to table of contents |
| uint32_t | ntoc | number of entries in table of contents |
| uint32_t | modtaboff | 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. file offset to module table |
| uint32_t | nmodtab | number of module table entries |
| uint32_t | extrefsymoff | 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. offset to referenced symbol table |
| uint32_t | nextrefsyms | number of referenced symbol table entries |
| uint32_t | indirectsymoff | 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. file offset to the indirect symbol table |
| uint32_t | nindirectsyms | number of indirect symbol table entries |
| uint32_t | extreloff | To support relocating an individual module in a library file quickly the external relocation entries for each module in the library need to be accessed efficiently. Since the relocation entries can't be accessed through the section headers for a library file they are separated into groups of local and external entries further grouped by module. In this case the presents of this load command who's extreloff, nextrel, locreloff and nlocrel fields are non-zero indicates that the relocation entries of non-merged sections are not referenced through the section structures (and the reloff and nreloc fields in the section headers are set to zero). Since the relocation entries are not accessed through the section headers this requires the r_address field to be something other than a section offset to identify the item to be relocated. In this case r_address is set to the offset from the vmaddr of the first LC_SEGMENT command. For MH_SPLIT_SEGS images r_address is set to the the offset from the vmaddr of the first read-write LC_SEGMENT command. The relocation entries are grouped by module and the module table entries have indexes and counts into them for the group of external relocation entries for that the module. For sections that are merged across modules there must not be any remaining external relocation entries for them (for merged sections remaining relocation entries must be local). offset to external relocation entries |
| uint32_t | nextrel | number of external relocation entries |
| uint32_t | locreloff | All the local relocation entries are grouped together (they are not grouped by their module since they are only used if the object is moved from it staticly link edited address). offset to local relocation entries |
| uint32_t | nlocrel | number of local relocation entries |
macroINDIRECT_SYMBOL_LOCAL
An indirect symbol table entry is simply a 32bit index into the symbol table
to the symbol that the pointer or stub is refering to. Unless it is for a
non-lazy symbol pointer section for a defined symbol which strip(1) as
removed. In which case it has the value INDIRECT_SYMBOL_LOCAL. If the
symbol was also absolute INDIRECT_SYMBOL_ABS is or'ed with that.
#define INDIRECT_SYMBOL_LOCAL 0x80000000
macroINDIRECT_SYMBOL_ABS
#define INDIRECT_SYMBOL_ABS 0x40000000
structdylib_table_of_contents
a table of contents entry
| uint32_t | symbol_index | the defined external symbol (index into the symbol table) |
| uint32_t | module_index | index into the module table this symbol is defined in |
structdylib_module
a module table entry
| uint32_t | module_name | the module name (index into string table) |
| uint32_t | iextdefsym | index into externally defined symbols |
| uint32_t | nextdefsym | number of externally defined symbols |
| uint32_t | irefsym | index into reference symbol table |
| uint32_t | nrefsym | number of reference symbol table entries |
| uint32_t | ilocalsym | index into symbols for local symbols |
| uint32_t | nlocalsym | number of local symbols |
| uint32_t | iextrel | index into external relocation entries |
| uint32_t | nextrel | number of external relocation entries |
| uint32_t | iinit_iterm | low 16 bits are the index into the init section, high 16 bits are the index into the term section |
| uint32_t | ninit_nterm | low 16 bits are the number of init section entries, high 16 bits are the number of term section entries |
| uint32_t | objc_module_info_addr | the (__OBJC,__module_info) section |
| uint32_t | objc_module_info_size | the (__OBJC,__module_info) section |
structdylib_module_64
a 64-bit module table entry
| uint32_t | module_name | the module name (index into string table) |
| uint32_t | iextdefsym | index into externally defined symbols |
| uint32_t | nextdefsym | number of externally defined symbols |
| uint32_t | irefsym | index into reference symbol table |
| uint32_t | nrefsym | number of reference symbol table entries |
| uint32_t | ilocalsym | index into symbols for local symbols |
| uint32_t | nlocalsym | number of local symbols |
| uint32_t | iextrel | index into external relocation entries |
| uint32_t | nextrel | number of external relocation entries |
| uint32_t | iinit_iterm | low 16 bits are the index into the init section, high 16 bits are the index into the term section |
| uint32_t | ninit_nterm | low 16 bits are the number of init section entries, high 16 bits are the number of term section entries |
| uint32_t | objc_module_info_size | the (__OBJC,__module_info) section |
| uint64_t | objc_module_info_addr | the (__OBJC,__module_info) section |
structdylib_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
<mach-o/nlist.h> as they are also used for symbol table entries.
| uint32_t:24 | isym | index into the symbol table |
| uint32_t:8 | flags | flags to indicate the type of reference |
structtwolevel_hints_command
The twolevel_hints_command contains the offset and number of hints in the
two-level namespace lookup hints table.
| uint32_t | cmd | LC_TWOLEVEL_HINTS |
| uint32_t | cmdsize | sizeof(struct twolevel_hints_command) |
| uint32_t | offset | offset to the hint table |
| uint32_t | nhints | number of hints in the hint table |
structtwolevel_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.
| uint32_t:8 | isub_image | index into the sub images |
| uint32_t:24 | itoc | index into the table of contents |
structprebind_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.
| uint32_t | cmd | LC_PREBIND_CKSUM |
| uint32_t | cmdsize | sizeof(struct prebind_cksum_command) |
| uint32_t | cksum | the check sum or zero |
structuuid_command
The uuid load command contains a single 128-bit unique random number that
identifies an object produced by the static link editor.
| uint32_t | cmd | LC_UUID |
| uint32_t | cmdsize | sizeof(struct uuid_command) |
| uint8_t[16] | uuid | the 128-bit uuid |
structrpath_command
The rpath_command contains a path which at runtime should be added to
the current run path used to find @rpath prefixed dylibs.
| uint32_t | cmd | LC_RPATH |
| uint32_t | cmdsize | includes string |
| union lc_str | path | path to add to run path |
structtarget_triple_command
The target_triple_command contains a string which specifies the
target triple (e.g. "arm64e-apple-macosx15.0.0") used to compile the code.
| uint32_t | cmd | LC_TARGET_TRIPLE |
| uint32_t | cmdsize | including string |
| union lc_str | triple | target triple string |
structlinkedit_data_command
The linkedit_data_command contains the offsets and sizes of a blob
of data in the __LINKEDIT segment.
| uint32_t | cmd | LC_CODE_SIGNATURE, LC_SEGMENT_SPLIT_INFO, LC_FUNCTION_STARTS, LC_DATA_IN_CODE, LC_DYLIB_CODE_SIGN_DRS, LC_ATOM_INFO, LC_LINKER_OPTIMIZATION_HINT, LC_DYLD_EXPORTS_TRIE, LC_FUNCTION_VARIANTS, LC_FUNCTION_VARIANT_FIXUPS, LC_DYLD_CHAINED_FIXUPS, or LC_LAZY_LOAD_DYLIB_INFO |
| uint32_t | cmdsize | sizeof(struct linkedit_data_command) |
| uint32_t | dataoff | file offset of data in __LINKEDIT segment |
| uint32_t | datasize | file size of data in __LINKEDIT segment |
structencryption_info_command
The encryption_info_command contains the file offset and size of an
of an encrypted segment.
| uint32_t | cmd | LC_ENCRYPTION_INFO |
| uint32_t | cmdsize | sizeof(struct encryption_info_command) |
| uint32_t | cryptoff | file offset of encrypted range |
| uint32_t | cryptsize | file size of encrypted range |
| uint32_t | cryptid | which enryption system, 0 means not-encrypted yet |
structencryption_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).
| uint32_t | cmd | LC_ENCRYPTION_INFO_64 |
| uint32_t | cmdsize | sizeof(struct encryption_info_command_64) |
| uint32_t | cryptoff | file offset of encrypted range |
| uint32_t | cryptsize | file size of encrypted range |
| uint32_t | cryptid | which enryption system, 0 means not-encrypted yet |
| uint32_t | pad | padding to make this struct's size a multiple of 8 bytes |
structversion_min_command
The version_min_command contains the min OS version on which this
binary was built to run.
| uint32_t | cmd | LC_VERSION_MIN_MACOSX or LC_VERSION_MIN_IPHONEOS or LC_VERSION_MIN_WATCHOS or LC_VERSION_MIN_TVOS |
| uint32_t | cmdsize | sizeof(struct min_version_command) |
| uint32_t | version | X.Y.Z is encoded in nibbles xxxx.yy.zz |
| uint32_t | sdk | X.Y.Z is encoded in nibbles xxxx.yy.zz |
structbuild_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.
| uint32_t | cmd | LC_BUILD_VERSION |
| uint32_t | cmdsize | sizeof(struct build_version_command) plus |
| uint32_t | platform | ntools * sizeof(struct build_tool_version) platform |
| uint32_t | minos | X.Y.Z is encoded in nibbles xxxx.yy.zz |
| uint32_t | sdk | X.Y.Z is encoded in nibbles xxxx.yy.zz |
| uint32_t | ntools | number of tool entries following this |
structbuild_tool_version
| uint32_t | tool | enum for the tool |
| uint32_t | version | version number of the tool |
macroPLATFORM_ANY
#define PLATFORM_ANY 0xFFFFFFFF
macroPLATFORM_MACOS
#define PLATFORM_MACOS 1
macroPLATFORM_IOS
#define PLATFORM_IOS 2
macroPLATFORM_TVOS
#define PLATFORM_TVOS 3
macroPLATFORM_WATCHOS
#define PLATFORM_WATCHOS 4
macroPLATFORM_BRIDGEOS
#define PLATFORM_BRIDGEOS 5
macroPLATFORM_MACCATALYST
#define PLATFORM_MACCATALYST 6
macroPLATFORM_IOSSIMULATOR
#define PLATFORM_IOSSIMULATOR 7
macroPLATFORM_TVOSSIMULATOR
#define PLATFORM_TVOSSIMULATOR 8
macroPLATFORM_WATCHOSSIMULATOR
#define PLATFORM_WATCHOSSIMULATOR 9
macroPLATFORM_DRIVERKIT
#define PLATFORM_DRIVERKIT 10
macroPLATFORM_VISIONOS
#define PLATFORM_VISIONOS 11
macroPLATFORM_VISIONOSSIMULATOR
#define PLATFORM_VISIONOSSIMULATOR 12
macroPLATFORM_FIRMWARE
#define PLATFORM_FIRMWARE 13
macroPLATFORM_SEPOS
#define PLATFORM_SEPOS 14
macroPLATFORM_MACOS_EXCLAVECORE
#define PLATFORM_MACOS_EXCLAVECORE 15
macroPLATFORM_MACOS_EXCLAVEKIT
#define PLATFORM_MACOS_EXCLAVEKIT 16
macroPLATFORM_IOS_EXCLAVECORE
#define PLATFORM_IOS_EXCLAVECORE 17
macroPLATFORM_IOS_EXCLAVEKIT
#define PLATFORM_IOS_EXCLAVEKIT 18
macroPLATFORM_TVOS_EXCLAVECORE
#define PLATFORM_TVOS_EXCLAVECORE 19
macroPLATFORM_TVOS_EXCLAVEKIT
#define PLATFORM_TVOS_EXCLAVEKIT 20
macroPLATFORM_WATCHOS_EXCLAVECORE
#define PLATFORM_WATCHOS_EXCLAVECORE 21
macroPLATFORM_WATCHOS_EXCLAVEKIT
#define PLATFORM_WATCHOS_EXCLAVEKIT 22
macroPLATFORM_VISIONOS_EXCLAVECORE
#define PLATFORM_VISIONOS_EXCLAVECORE 23
macroPLATFORM_VISIONOS_EXCLAVEKIT
#define PLATFORM_VISIONOS_EXCLAVEKIT 24
macroTOOL_SWIFT
#define TOOL_SWIFT 2
macroTOOL_LD
#define TOOL_LD 3
macroTOOL_LLD
#define TOOL_LLD 4
macroTOOL_AIRLLD
#define TOOL_AIRLLD 1025
macroTOOL_AIRNT
#define TOOL_AIRNT 1026
macroTOOL_AIRNT_PLUGIN
#define TOOL_AIRNT_PLUGIN 1027
macroTOOL_AIRPACK
#define TOOL_AIRPACK 1028
macroTOOL_GPUARCHIVER
#define TOOL_GPUARCHIVER 1031
macroTOOL_METAL_FRAMEWORK
#define TOOL_METAL_FRAMEWORK 1032
structdyld_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.
| uint32_t | cmd | LC_DYLD_INFO or LC_DYLD_INFO_ONLY |
| uint32_t | cmdsize | sizeof(struct dyld_info_command) |
| uint32_t | rebase_off | 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: <seg-index, seg-offset, type> 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. file offset to rebase info |
| uint32_t | rebase_size | size of rebase info |
| uint32_t | bind_off | 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: <seg-index, seg-offset, type, symbol-library-ordinal, symbol-name, addend> 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. file offset to binding info |
| uint32_t | bind_size | size of binding info |
| uint32_t | weak_bind_off | 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. file offset to weak binding info |
| uint32_t | weak_bind_size | size of weak binding info |
| uint32_t | lazy_bind_off | 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. file offset to lazy binding info |
| uint32_t | lazy_bind_size | size of lazy binding infs |
| uint32_t | export_off | 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. file offset to lazy binding info |
| uint32_t | export_size | size of lazy binding infs |
macroREBASE_TYPE_POINTER
The following are used to encode rebasing information
#define REBASE_TYPE_POINTER 1
macroREBASE_TYPE_TEXT_ABSOLUTE32
#define REBASE_TYPE_TEXT_ABSOLUTE32 2
macroREBASE_TYPE_TEXT_PCREL32
#define REBASE_TYPE_TEXT_PCREL32 3
macroREBASE_OPCODE_MASK
#define REBASE_OPCODE_MASK 0xF0
macroREBASE_IMMEDIATE_MASK
#define REBASE_IMMEDIATE_MASK 0x0F
macroREBASE_OPCODE_DONE
#define REBASE_OPCODE_DONE 0x00
macroREBASE_OPCODE_SET_TYPE_IMM
#define REBASE_OPCODE_SET_TYPE_IMM 0x10
macroREBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
#define REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB 0x20
macroREBASE_OPCODE_ADD_ADDR_ULEB
#define REBASE_OPCODE_ADD_ADDR_ULEB 0x30
macroREBASE_OPCODE_ADD_ADDR_IMM_SCALED
#define REBASE_OPCODE_ADD_ADDR_IMM_SCALED 0x40
macroREBASE_OPCODE_DO_REBASE_IMM_TIMES
#define REBASE_OPCODE_DO_REBASE_IMM_TIMES 0x50
macroREBASE_OPCODE_DO_REBASE_ULEB_TIMES
#define REBASE_OPCODE_DO_REBASE_ULEB_TIMES 0x60
macroREBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB
#define REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB 0x70
macroREBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB
#define REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB 0x80
macroBIND_TYPE_POINTER
The following are used to encode binding information
#define BIND_TYPE_POINTER 1
macroBIND_TYPE_TEXT_ABSOLUTE32
#define BIND_TYPE_TEXT_ABSOLUTE32 2
macroBIND_TYPE_TEXT_PCREL32
#define BIND_TYPE_TEXT_PCREL32 3
macroBIND_SPECIAL_DYLIB_SELF
#define BIND_SPECIAL_DYLIB_SELF 0
macroBIND_SPECIAL_DYLIB_MAIN_EXECUTABLE
#define BIND_SPECIAL_DYLIB_MAIN_EXECUTABLE -1
macroBIND_SPECIAL_DYLIB_FLAT_LOOKUP
#define BIND_SPECIAL_DYLIB_FLAT_LOOKUP -2
macroBIND_SPECIAL_DYLIB_WEAK_LOOKUP
#define BIND_SPECIAL_DYLIB_WEAK_LOOKUP -3
macroBIND_SYMBOL_FLAGS_WEAK_IMPORT
#define BIND_SYMBOL_FLAGS_WEAK_IMPORT 0x1
macroBIND_SYMBOL_FLAGS_NON_WEAK_DEFINITION
#define BIND_SYMBOL_FLAGS_NON_WEAK_DEFINITION 0x8
macroBIND_OPCODE_MASK
#define BIND_OPCODE_MASK 0xF0
macroBIND_IMMEDIATE_MASK
#define BIND_IMMEDIATE_MASK 0x0F
macroBIND_OPCODE_DONE
#define BIND_OPCODE_DONE 0x00
macroBIND_OPCODE_SET_DYLIB_ORDINAL_IMM
#define BIND_OPCODE_SET_DYLIB_ORDINAL_IMM 0x10
macroBIND_OPCODE_SET_DYLIB_ORDINAL_ULEB
#define BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB 0x20
macroBIND_OPCODE_SET_DYLIB_SPECIAL_IMM
#define BIND_OPCODE_SET_DYLIB_SPECIAL_IMM 0x30
macroBIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM
#define BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM 0x40
macroBIND_OPCODE_SET_TYPE_IMM
#define BIND_OPCODE_SET_TYPE_IMM 0x50
macroBIND_OPCODE_SET_ADDEND_SLEB
#define BIND_OPCODE_SET_ADDEND_SLEB 0x60
macroBIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
#define BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB 0x70
macroBIND_OPCODE_ADD_ADDR_ULEB
#define BIND_OPCODE_ADD_ADDR_ULEB 0x80
macroBIND_OPCODE_DO_BIND
#define BIND_OPCODE_DO_BIND 0x90
macroBIND_OPCODE_DO_BIND_ADD_ADDR_ULEB
#define BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB 0xA0
macroBIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED
#define BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED 0xB0
macroBIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB
#define BIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB 0xC0
macroBIND_OPCODE_THREADED
#define BIND_OPCODE_THREADED 0xD0
macroBIND_SUBOPCODE_THREADED_SET_BIND_ORDINAL_TABLE_SIZE_ULEB
#define BIND_SUBOPCODE_THREADED_SET_BIND_ORDINAL_TABLE_SIZE_ULEB 0x00
macroBIND_SUBOPCODE_THREADED_APPLY
#define BIND_SUBOPCODE_THREADED_APPLY 0x01
macroEXPORT_SYMBOL_FLAGS_KIND_MASK
The following are used on the flags byte of a terminal node
in the export information.
#define EXPORT_SYMBOL_FLAGS_KIND_MASK 0x03
macroEXPORT_SYMBOL_FLAGS_KIND_REGULAR
#define EXPORT_SYMBOL_FLAGS_KIND_REGULAR 0x00
macroEXPORT_SYMBOL_FLAGS_KIND_THREAD_LOCAL
#define EXPORT_SYMBOL_FLAGS_KIND_THREAD_LOCAL 0x01
macroEXPORT_SYMBOL_FLAGS_KIND_ABSOLUTE
#define EXPORT_SYMBOL_FLAGS_KIND_ABSOLUTE 0x02
macroEXPORT_SYMBOL_FLAGS_WEAK_DEFINITION
#define EXPORT_SYMBOL_FLAGS_WEAK_DEFINITION 0x04
macroEXPORT_SYMBOL_FLAGS_REEXPORT
#define EXPORT_SYMBOL_FLAGS_REEXPORT 0x08
macroEXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER
#define EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER 0x10
macroEXPORT_SYMBOL_FLAGS_STATIC_RESOLVER
#define EXPORT_SYMBOL_FLAGS_STATIC_RESOLVER 0x20
structlinker_option_command
The linker_option_command contains linker options embedded in object files.
| uint32_t | cmd | LC_LINKER_OPTION only used in MH_OBJECT filetypes |
| uint32_t | cmdsize | |
| uint32_t | count | number of strings |
structsymseg_command
The symseg_command contains the offset and size of the GNU style
symbol table information as described in the header file <symseg.h>.
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).
| uint32_t | cmd | LC_SYMSEG |
| uint32_t | cmdsize | sizeof(struct symseg_command) |
| uint32_t | offset | symbol segment offset |
| uint32_t | size | symbol segment size in bytes |
structident_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).
| uint32_t | cmd | LC_IDENT |
| uint32_t | cmdsize | strings that follow this command |
structfvmfile_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).
| uint32_t | cmd | LC_FVMFILE |
| uint32_t | cmdsize | includes pathname string |
| union lc_str | name | files pathname |
| uint32_t | header_addr | files virtual address |
structentry_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.
| uint32_t | cmd | LC_MAIN only used in MH_EXECUTE filetypes |
| uint32_t | cmdsize | 24 |
| uint64_t | entryoff | file (__TEXT) offset of main() |
| uint64_t | stacksize | if not zero, initial stack size |
structsource_version_command
The source_version_command is an optional load command containing
the version of the sources used to build the binary.
| uint32_t | cmd | LC_SOURCE_VERSION |
| uint32_t | cmdsize | 16 |
| uint64_t | version | A.B.C.D.E packed as a24.b10.c10.d10.e10 |
structdata_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.
| uint32_t | offset | from mach_header to start of data range |
| uint16_t | length | number of bytes in data range |
| uint16_t | kind | a DICE_KIND_* value |
macroDICE_KIND_DATA
#define DICE_KIND_DATA 0x0001
macroDICE_KIND_JUMP_TABLE8
#define DICE_KIND_JUMP_TABLE8 0x0002
macroDICE_KIND_JUMP_TABLE16
#define DICE_KIND_JUMP_TABLE16 0x0003
macroDICE_KIND_JUMP_TABLE32
#define DICE_KIND_JUMP_TABLE32 0x0004
macroDICE_KIND_ABS_JUMP_TABLE32
#define DICE_KIND_ABS_JUMP_TABLE32 0x0005
structtlv_descriptor
Sections of type S_THREAD_LOCAL_VARIABLES contain an array
of tlv_descriptor structures.
| void *(*)(struct tlv_descriptor *) | thunk | |
| unsigned long | key | |
| unsigned long | offset |
structnote_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.
| uint32_t | cmd | LC_NOTE |
| uint32_t | cmdsize | sizeof(struct note_command) |
| char[16] | data_owner | owner name for this LC_NOTE |
| uint64_t | offset | file offset of this data |
| uint64_t | size | length of data region |
structfileset_entry_command
LC_FILESET_ENTRY commands describe constituent Mach-O files that are part
of a fileset. In one implementation, entries are dylibs with individual
mach headers and repositionable text and data segments. Each entry is
further described by its own mach header.
| uint32_t | cmd | LC_FILESET_ENTRY |
| uint32_t | cmdsize | includes entry_id string |
| uint64_t | vmaddr | memory address of the entry |
| uint64_t | fileoff | file offset of the entry |
| union lc_str | entry_id | contained entry id |
| uint32_t | reserved | reserved |