Enum mach_object::LoadCommand[−][src]

pub enum LoadCommand {
    Segment {
        segname: String,
        vmaddr: usize,
        vmsize: usize,
        fileoff: usize,
        filesize: usize,
        maxprot: vm_prot_t,
        initprot: vm_prot_t,
        flags: SegmentFlags,
        sections: Vec<Rc<Section>>,
    },
    Segment64 {
        segname: String,
        vmaddr: usize,
        vmsize: usize,
        fileoff: usize,
        filesize: usize,
        maxprot: vm_prot_t,
        initprot: vm_prot_t,
        flags: SegmentFlags,
        sections: Vec<Rc<Section>>,
    },
    IdFvmLib(FvmLib),
    LoadFvmLib(FvmLib),
    IdDyLib(DyLib),
    LoadDyLib(DyLib),
    LoadWeakDyLib(DyLib),
    ReexportDyLib(DyLib),
    LoadUpwardDylib(DyLib),
    LazyLoadDylib(DyLib),
    Rpath(String),
    IdDyLinker(LcString),
    LoadDyLinker(LcString),
    DyLdEnv(LcString),
    SymTab {
        symoff: u32,
        nsyms: u32,
        stroff: u32,
        strsize: u32,
    },
    DySymTab {
        ilocalsym: u32,
        nlocalsym: u32,
        iextdefsym: u32,
        nextdefsym: u32,
        iundefsym: u32,
        nundefsym: u32,
        tocoff: u32,
        ntoc: u32,
        modtaboff: u32,
        nmodtab: u32,
        extrefsymoff: u32,
        nextrefsyms: u32,
        indirectsymoff: u32,
        nindirectsyms: u32,
        extreloff: u32,
        nextrel: u32,
        locreloff: u32,
        nlocrel: u32,
    },
    Uuid(Uuid),
    CodeSignature(LinkEditData),
    SegmentSplitInfo(LinkEditData),
    FunctionStarts(LinkEditData),
    DataInCode(LinkEditData),
    DylibCodeSignDrs(LinkEditData),
    LinkerOptimizationHint(LinkEditData),
    VersionMin {
        target: BuildTarget,
        version: VersionTag,
        sdk: VersionTag,
    },
    DyldInfo {
        rebase_off: u32,
        rebase_size: u32,
        bind_off: u32,
        bind_size: u32,
        weak_bind_off: u32,
        weak_bind_size: u32,
        lazy_bind_off: u32,
        lazy_bind_size: u32,
        export_off: u32,
        export_size: u32,
    },
    EntryPoint {
        entryoff: u64,
        stacksize: u64,
    },
    SourceVersion(SourceVersionTag),
    UnixThread {
        flavor: u32,
        count: u32,
        state: ThreadState,
    },
    SubFramework(LcString),
    SubUmbrella(LcString),
    SubClient(LcString),
    SubLibrary(LcString),
    LinkerOption(Vec<String>),
    Routines {
        init_address: u32,
        init_module: u32,
    },
    Routines64 {
        init_address: u64,
        init_module: u64,
    },
    EncryptionInfo {
        offset: u32,
        size: u32,
        id: u32,
    },
    EncryptionInfo64 {
        offset: u32,
        size: u32,
        id: u32,
    },
    TwoLevelHints {
        offset: u32,
        nhints: u32,
    },
    BuildVersion(BuildVersion),
    Command {
        cmd: u32,
        payload: Vec<u8>,
    },
}

The load commands directly follow the mach header.

Variants

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.

Fields of Segment

segment name

memory address of this segment

memory size of this segment

file offset of this segment

amount to map from the file

maximum VM protection

initial VM protection

flags

sections

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.

Fields of Segment64

segment name

memory address of this segment

memory size of this segment

file offset of this segment

amount to map from the file

maximum VM protection

initial VM protection

flags

sections

fixed VM shared library identification

load a specified fixed VM shared library

dynamically linked shared lib ident

load a dynamically linked shared library

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

load and re-export dylib

load upward dylib

delay load of dylib until first use

add a runtime search path for shared libraries

dynamic linker identification

load a dynamic linker

string for dyld to treat like environment variable

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

Fields of SymTab

symbol table offset

number of symbol table entries

string table offset

string table size in bytes

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.

Fields of DySymTab

index to local symbols

number of local symbols

index to externally defined symbols

number of externally defined symbols

index to undefined symbols

number of undefined symbols

file offset to table of contents

number of entries in table of contents

file offset to module table

number of module table entries

offset to referenced symbol table

number of referenced symbol table entries

file offset to the indirect symbol table

number of indirect symbol table entries

offset to external relocation entries

number of external relocation entries

offset to local relocation entries

number of local relocation entries

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

local of code signature

local of info to split segments

compressed table of function start addresses

table of non-instructions in __text

Code signing DRs copied from linked dylibs

optimization hints in MH_OBJECT files

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

Fields of VersionMin

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.

Fields of DyldInfo

file offset to rebase info

size of rebase info

file offset to binding info

size of binding info

file offset to weak binding info

size of weak binding info

file offset to lazy binding info

size of lazy binding infs

file offset to lazy binding info

size of lazy binding infs

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.

Fields of EntryPoint

file (__TEXT) offset of main()

if not zero, initial stack size

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

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 unsigned long constant for the flavor of that data structure, an that is the count of longs 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.

Fields of UnixThread

flavor of thread state

count of longs in thread state

thread state for this flavor

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.

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.

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

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

The linker_option_command contains linker options embedded in object files.

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.

Fields of Routines

address of initialization routine

index into the module table that the init routine is defined in

Fields of Routines64

address of initialization routine

index into the module table that the init routine is defined in

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

Fields of EncryptionInfo

file offset of encrypted range

file size of encrypted range

which enryption system, 0 means not-encrypted yet

Fields of EncryptionInfo64

file offset of encrypted range

file size of encrypted range

which enryption system, 0 means not-encrypted yet

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

Fields of TwoLevelHints

offset to the hint table

number of hints in the hint table

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.

Fields of Command

type of load command

command in bytes

Methods

impl LoadCommand
[src]

Trait Implementations

impl Debug for LoadCommand
[src]

Formats the value using the given formatter. Read more

impl Clone for LoadCommand
[src]

Returns a copy of the value. Read more

Performs copy-assignment from source. Read more

Auto Trait Implementations

impl !Send for LoadCommand

impl !Sync for LoadCommand