regular (S_REGULAR)

A regular section may contain any kind of data and gets no special processing from the link editor. This is the default section type. Examples of regular sections include program instructions or initialized data.

cstring_literals (S_CSTRING_LITERALS)

A cstring_literals section contains null-terminated literal C language character strings. The link editor places only one copy of each literal into the output file’s section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. The last byte in a section of this type must be a null byte, and the strings can’t contain null bytes in their bodies. An example of a cstring_literals section is one for the literal strings that appear in the body of an ANSI C function where the compiler chooses to make such strings read only.

4byte_literals (S_4BYTE_LITERALS)

A 4byte_literals section contains 4-byte literal constants. The link editor places only one copy of each literal into the output file’s section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. An example of a 4byte_literals section is one in which single-precision floating-point constants are stored for a RISC machine (these would normally be stored as immediates in CISC machine code).

8byte_literals (S_8BYTE_LITERALS)

An 8byte_literals section contains 8-byte literal constants. The link editor places only one copy of each literal into the output file’s section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. An example of a 8byte_literals section is one in which double-precision floating-point constants are stored for a RISC machine (these would normally be stored as immediates in CISC machine code).

literal_pointers (S_LITERAL_POINTERS)

A literal_pointers section contains 4-byte pointers to literals in a literal section. The link editor places only one copy of a pointer into the output file’s section for each pointer to a literal with the same contents. The link editor also relocates references to each literal pointer to the one copy in the output file. There must be exactly one relocation entry for each literal pointer in this section, and all references to literals in this section must be inside the address range for the specific literal being referenced. The relocation entries can be external relocation entries referring to undefined symbols if those symbols identify literals in another object file. An example of a literal_pointers section is one containing selector references generated by the Objective-C compiler.

symbol_stubs (S_SYMBOL_STUBS)

A symbol_stubs section contains symbol stubs, which are sequences of machine instructions (all the same size) used for lazily binding undefined function calls at runtime. If a call to an undefined function is made, the compiler outputs a call to a symbol stub instead, and tags the stub with an indirect symbol that indicates what symbol the stub is for. On transfer to a symbol stub, a program executes instructions that eventually reach the code for the indirect symbol associated with that stub. Here’s a sample of assembly code based on a function func() containing only a call to the undefined function foo():

    .text

    .align 2

    .globl _func

 _func:

    b L_foo$stub

    .symbol_stub

 L_foo$stub:                            ;

    .indirect_symbol _foo               ;

    lis r11,ha16(L_foo$lazy_ptr)        ;

    lwz r12,lo16(L_foo$lazy_ptr)(r11)   ; the symbol stub

    mtctr r12                           ;

    addi r11,r11,lo16(L_foo$lazy_ptr)   ;

    bctr                                ;

    .lazy_symbol_pointer

 L_foo$lazy_ptr:                        ;

    .indirect_symbol _foo               ; the symbol pointer

    .long dyld_stub_binding_helper      ; to be replaced by _foo's address

The symbol-stub sections in the IA-32 architecture—instead of using a stub and a lazy pointer—use one branch instruction that specifies the target. This is the corresponding IA-32 assembly code:

    .text

    .align 2

    .globl _func

_func:

    pushl   %ebp

    movl    %esp, %ebp

    subl    $8, %esp

    call    L_foo$stub

    leave

    ret

    .symbol_stub

L_foo$stub:

     .indirect_symbol _foo

     hlt ; hlt ; hlt ; hlt ; hlt

In the assembly code, _func branches to L_foo$stub, which is responsible for finding the definition of the function foo(). On PPC (and PPC64), L_foo$stub jumps to the contents of L_foo$lazy_ptr. This value is initially the address of the dyld_stub_binding_helper code, which after executing causes it to overwrite the contents of L_foo$lazy_ptr with the address of the real function, _foo, and jump to _foo.

On IA-32, the branch instruction points to the dynamic linker. The first time the stub is called, the dynamic linker modifies the instruction so that it jumps to the real function in subsequent calls.

The indirect symbol entries for _foo provide information to the static and dynamic linkers for binding the symbol stub. Each symbol stub and lazy pointer entry must have exactly one such indirect symbol, associated with the first address in the stub or pointer entry. See .indirect_symbol for more information.

The static link editor places only one copy of each stub into the output file’s section for a particular indirect symbol, and relocates all references to the stubs with the same indirect symbol to the stub in the output file. Further, the static link editor eliminates a stub if it determines that the target is in the same linkage unit and doesn’t need redirecting at runtime. No global symbols can be defined in symbol_stubs sections.

On PPC, the stub can refer only to itself, one lazy symbol pointer (referring to the same indirect symbol as the stub), and the dyld_stub_binding_helper() function.

lazy_symbol_pointers (S_LAZY_SYMBOL_POINTERS)

A lazy_symbol_pointers section contains 4-byte symbol pointers that eventually contain the value of the indirect symbol associated with the pointer. These pointers are used by symbol stubs to lazily bind undefined function calls at runtime. A lazy symbol pointer initially contains an address in the symbol stub of instructions that cause the symbol pointer to be bound to the function definition (in the example in symbol_stubs (S_SYMBOL_STUBS), the lazy pointer L_foo$lazy_ptr initially contains the address for dyld_stub_binding_helper but gets overwritten with the address for _foo). The dynamic link editor binds the indirect symbol associated with the lazy symbol pointer by overwriting it with the value of the symbol.

The static link editor places a copy of a lazy pointer in the output file only if the corresponding symbol stub is in the output file. Only the corresponding symbol stub can make a reference to a lazy symbol pointer, and no global symbols can be defined in this type of section. There must be one indirect symbol associated with each lazy symbol pointer. An example of a lazy_symbol_pointers section is one in which the compiler has generated calls to undefined functions, each of which can be bound lazily at the time of the first call to the function.

non_lazy_symbol_pointers (S_NON_LAZY_SYMBOL_POINTERS)

A non_lazy_symbol_pointers section contains 4-byte symbol pointers that contain the value of the indirect symbol associated with a pointer that may be set at any time before any code makes a reference to it. These pointers are used by the code to reference undefined symbols. Initially these pointers have no interesting value but get overwritten by the dynamic link editor with the value of the symbol for the associated indirect symbol before any code can make a reference to it.

The static link editor places only one copy of each non-lazy pointer for its indirect symbol into the output file and relocates all references to the pointer with the same indirect symbol to the pointer in the output file. The static link editor further can fill in the pointer with the value of the symbol if a definition of the indirect symbol for that pointer is present in the output file. No global symbols can be defined in this type of section. There must be one indirect symbol associated with each non-lazy symbol pointer. An example of a non_lazy_symbol_pointers section is one in which the compiler has generated code to indirectly reference undefined symbols to be bound at runtime—this preserves the sharing of the machine instructions by allowing the dynamic link editor to update references without writing on the instructions.

Here's an example of assembly code referencing an element in the undefined structure. The corresponding C code would be:

struct s {

        int member1, member2;

    };

    extern struct s bar;

    int func()

    {

        return(bar.member2);

    }

The PowerPC assembly code might look like this:

    .text

    .align 2

    .globl _func

 _func:

    lis r3,ha16(L_bar$non_lazy_ptr)

    lwz r2,lo16(L_bar$non_lazy_ptr)(r3)

    lwz r3,4(r2)

    blr

    .non_lazy_symbol_pointer

 L_bar$non_lazy_ptr:

    .indirect_symbol _bar

    .long 0

mod_init_funcs (S_MOD_INIT_FUNC_POINTERS)

A mod_init_funcs section contains 4-byte pointers to functions that are to be called just after the module containing the pointer is bound into the program by the dynamic link editor. The static link editor does no special processing for this section type except for disallowing section ordering. This is done to maintain the order the functions are called (which is the order their pointers appear in the original module). There must be exactly one relocation entry for each pointer in this section. An example of a mod_init_funcs section is one in which the compiler has generated code to call C++ constructors for modules that get dynamically bound at runtime.

mod_term_funcs (S_MOD_TERM_FUNC_POINTERS)

A mod_term_funcs section contains 4-byte pointers to functions that are to be called just before the module containing the pointer is unloaded by the dynamic link editor or the program is terminated. The static link editor does no special processing for this section type except for disallowing section ordering. This is done to maintain the order the functions are called (which is the order their pointers appear in the original module). There must be exactly one relocation entry for each pointer in this section. An example of a mod_term_funcs section is one in which the compiler has generated code to call C++ destructors for modules that get dynamically bound at runtime.

coalesced (S_COALESCED)

A coalesced section can contain any instructions or data and is used when more than one definition of a symbol could be defined in multiple object files being linked together. The static link editor keeps the data associated with the coalesced symbol from the first object file it links and silently discards the data from other object files. An example of a coalesced section is one in which the compiler has generated code for implicit instantiations of C++ templates.

none (0)

No attributes for this section. This is the default section attribute.

S_ATTR_SOME_INSTRUCTIONS

This attribute is set by the assembler whenever it assembles a machine instruction in a section. There is no directive associated with it, since you cannot set it yourself. It is used by the dynamic link editor together with S_ATTR_EXT_RELOC and S_ATTR_LOC_RELOC, set by the static link editor, to know it must flush the cache and other processor-related functions when it relocates instructions by writing on them.

no_dead_strip (S_ATTR_NO_DEAD_STRIP)

The no_dead_strip section attribute specifies that a particular section must not be dead-stripped. See Directives for Dead-Code Stripping for more information.

no_toc (S_ATTR_NO_TOC)

The no_toc section attribute means that the global symbols in this section are not to be used in the table of contents of a static library as produced by the program ranlib(1). This is normally used with a coalesced section when it is expected that each object file has a definition of the symbols that it uses.

live_support (S_ATTR_LIVE_SUPPORT)

The live_support section attribute specifies that a section’s blocks must not be dead-stripped if they reference code that is live, but the reference is undetectable. See Directives for Dead-Code Stripping for more information.

pure_instructions (S_ATTR_PURE_INSTRUCTIONS)

The pure_instructions attribute means that this section contains nothing but machine instructions. This attribute would be used for the (__TEXT,__text) section of OS X compilers and sections that have a section type of symbol_stubs.

strip_static_syms (S_ATTR_STRIP_STATIC_SYMS)

The strip_static_syms section attribute means that the static symbols in this section can be stripped from linked images that are used with the dynamic linker when debugging symbols are also stripped. This is normally used with a coalesced section that has private extern symbols, so that after linking and the private extern symbols have been turned into static symbols they can be stripped to save space in the linked image.

self_modifying_code (S_ATTR_SELF_MODIFYING_CODE)

The self_modifying_code section attribute identifies a section with code that can be modified by the dynamic linker. For example, IA-32 symbol stubs are implemented as branch instructions that initially point to the dynamic linker but are modified by the dynamic linker to point to the real symbol.

.text

This is equivalent to .section __TEXT,__text,regular,pure_instructions when the default -dynamic flag is in effect and equivalent to .section __TEXT,__text,regular when the -static flag is specified.

The compiler places only machine instructions in the (__TEXT,__text) section (no read-only data, jump tables or anything else). With this, the entire (__TEXT,__text) section is pure instructions and tools that operate on object files. The runtime can take advantage of this to locate the instructions of the program and not get confused with data that could have been mixed in. To make this work, all runtime support code linked into the program must also obey this rule (all OS X library code follows this rule).

.const

This is equivalent to .section __TEXT,__const

The compiler places all data declared const and all jump tables it generates for switch statements in this section.

.static_const

This is equivalent to .section __TEXT,__static_const

This is not currently used by the compiler. It was added to the assembler so that the compiler may separate global and static const data into separate sections if it wished to.

.cstring

This is equivalent to .section __TEXT,__cstring, cstring_literals

This section is marked with the section type cstring_literals, which the link editor recognizes. The link editor merges the like literal C strings in all the input object files to one unique C string in the output file. Therefore this section must contain only C strings (a C string in a sequence of bytes that ends in a null byte, \0, and does not contain any other null bytes except its terminator). The compiler places literal C strings found in the code that are not initializers and do not contain any embedded nulls in this section.

.literal4

This is equivalent to .section __TEXT,__literal4,4byte_literals

This section is marked with the section type 4byte_literals, which the link editor recognizes. The link editor can then merge the like 4 byte literals in all the input object files to one unique 4 byte literal in the output file. Therefore, this section must contain only 4 byte literals. This is typically intended for single precision floating-point constants and the compiler uses this section for that purpose. On some architectures it is more efficient to place these constants in line as immediates as part of the instruction.

.literal8

This is equivalent to .section __TEXT,__literal8,8byte_literals

This section is marked with the section type 8byte_literals, which the link editor recognizes. The link editor then can merge the like 8 byte literals in all the input object files to one unique 8 byte literal in the output file. Therefore, this section must contain only 8 byte literals. This is typically intended for double precision floating-point constants and the compiler uses this section for that purpose. On some architectures it is more efficient to place these constants in line as immediates as part of the instruction.

.literal16

This is equivalent to .section __TEXT,__literal16,16byte_literals

This section is marked with the section type 16byte_literals, which the link editor recognizes. The link editor can then merge the like 16 byte literals in all the input object files to one unique 16 byte literal in the output file. Therefore, this section must contain only 16 byte literals. This is typically intended for vector constants and the compiler uses this section for that purpose.

.constructor

This is equivalent to .section __TEXT,__constructor

.destructor

This is equivalent to .section __TEXT,__destructor

The .constructor and .destructor sections are used by the C++ runtime system, and are reserved exclusively for the C++ compiler.

.fvmlib_init0

This is equivalent to .section __TEXT,__fvmlib_init0

.fvmlib_init1

This is equivalent to .section __TEXT,__fvmlib_init1

The .fvmlib_init0 and .fvmlib_init1 sections are used by the obsolete fixed virtual memory shared library initialization. The compiler doesn't place anything in these sections, as they are reserved exclusively for the obsolete shared library mechanism.

.symbol_stub

This section is of type symbol_stubs and has the attribute pure_instructions. The compiler places symbol stubs in this section for undefined functions that are called in the module. This is the standard symbol stub section for nonposition-independent code.

Symbol stubs are implemented differently on PPC (and PPC64) and on IA-32. The following sections describe each implementation.

        .symbol_stub

L_foo$stub:

        .indirect_symbol _foo

        lis     r11,ha16(L_foo$lazy_ptr)

        lwz     r12,lo16(L_foo$lazy_ptr)(r11)

        mtctr   r12

        addi    r11,r11,lo16(L_foo$lazy_ptr)

        bctr

        .lazy_symbol_pointer

L_foo$lazy_ptr:

        .indirect_symbol _foo

        .long   dyld_stub_binding_helper

        .section __IMPORT,__jump_table,symbol_stubs,self_modifying_code+pure_instructions,5

L_foo$stub:

        .indirect_symbol _foo

        hlt ; hlt ; hlt ; hlt ; hlt

.picsymbol_stub

In PowerPC, this directive translates to .section __TEXT, __picsymbolstub1, symbol_stubs, pure_instructions, NBYTES.

This section is of type symbol_stubs and has the attribute pure_instructions. The compiler places symbol stubs in this section for undefined functions that are called in the module. This is the standard symbol stub section for position-independent code. The value of NBYTES is dependent on the target architecture.

The standard position-independent symbol stub for the PowerPC is 36 bytes and has an alignment of 4 bytes (.align 2). For example, a stub for thesymbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr):

    .picsymbol_stub

 L_foo$stub:

    .indirect_symbol _foo

    mflr r0

    bcl 20,31,L0$_foo

 L0$_foo:

    mflr r11

    addis r11,r11,ha16(L_foo$lazy_ptr - L0$_foo)

    mtlr r0

    lwz r12,lo16(L_foo$lazy_ptr - L0$_foo)(r11)

    mtctr r12

    addi r11,r11,lo16(L_foo$lazy_ptr - L0$_foo)

    bctr

.data

This is equivalent to .section __DATA, __data

The compiler places all non-const initialized data (even initialized to zero) in this section.

.static_data

This is equivalent to .section __DATA, __static_data

This is not currently used by the compiler. It was added to the assembler so that the compiler could separate global and static data symbol into separate sections if it wished to.

.const_data

This is equivalent to .section __DATA, __const, regular.

This section is of type regular and has no attributes. This section is used when dynamic code is being compiled for const data that must be initialized.

.lazy_symbol_pointer

This is equivalent to .section __DATA, __la_symbol_ptr,lazy_symbol_pointers

This section is of type lazy_symbol_pointers and has no attributes. The compiler places a lazy symbol pointer in this section for each symbol stub it creates for undefined functions that are called in the module. (See .symbol_stub for examples.) This section has an alignment of 4 bytes (.align 2).

.non_lazy_symbol_pointer

This is equivalent to .section __DATA, __nl_symbol_ptr,non_lazy_symbol_pointers

This section is of type non_lazy_symbol_pointers and has no attributes. The compiler places a non-lazy symbol pointer in this section for each undefined symbol referenced by the module (except for function calls). This section has an alignment of 4 bytes (.align 2).

.mod_init_func

This is equivalent to .section __DATA, __mod_init_func, mod_init_funcs

This section is of type mod_init_funcs and has no attributes. The C++ compiler places a pointer to a function in this section for each function it creates to call the constructors (if the module has them).

.mod_term_func

This is equivalent to .section __DATA, __mod_term_func, mod_term_funcs

This section is of type mod_term_funcs and has no attributes. The C++ compiler places a pointer to a function in this section for each function it creates to call the destructors (if the module has them).

.dyld

This is equivalent to .section __DATA, __dyld,regular

This section is of type regular and has no attributes. This section is used by the dynamic link editor. The compiler doesn’t place anything in this section, as it is reserved exclusively for the dynamic link editor.