Annotation of GNUtools/cctools/include/mach-o/loader.h, revision 1.1.1.1

1.1       root        1: #ifndef _MACHO_LOADER_H_
                      2: #define _MACHO_LOADER_H_
                      3: 
                      4: /*
                      5:  * This file describes the format of mach object files.
                      6:  */
                      7: 
                      8: /*
                      9:  * <mach/machine.h> is needed here for the cpu_type_t and cpu_subtype_t types
                     10:  * and contains the constants for the possible values of these types.
                     11:  */
                     12: #import <mach/machine.h>
                     13: 
                     14: /*
                     15:  * <mach/vm_prot.h> is needed here for the vm_prot_t type and contains the 
                     16:  * constants that are or'ed together for the possible values of this type.
                     17:  */
                     18: #import <mach/vm_prot.h>
                     19: 
                     20: /*
                     21:  * <machine/thread_status.h> is expected to define the flavors of the thread
                     22:  * states and the structures of those flavors for each machine.
                     23:  */
                     24: #import <mach/machine/thread_status.h>
                     25: #import <architecture/byte_order.h>
                     26: 
                     27: /*
                     28:  * The mach header appears at the very beginning of the object file.
                     29:  */
                     30: struct mach_header {
                     31:        unsigned long   magic;          /* mach magic number identifier */
                     32:        cpu_type_t      cputype;        /* cpu specifier */
                     33:        cpu_subtype_t   cpusubtype;     /* machine specifier */
                     34:        unsigned long   filetype;       /* type of file */
                     35:        unsigned long   ncmds;          /* number of load commands */
                     36:        unsigned long   sizeofcmds;     /* the size of all the load commands */
                     37:        unsigned long   flags;          /* flags */
                     38: };
                     39: 
                     40: /* Constant for the magic field of the mach_header */
                     41: #define        MH_MAGIC        0xfeedface      /* the mach magic number */
                     42: #define MH_CIGAM       NXSwapInt(MH_MAGIC)
                     43: 
                     44: /*
                     45:  * The layout of the file depends on the filetype.  For all but the MH_OBJECT
                     46:  * file type the segments are padded out and aligned on a segment alignment
                     47:  * boundary for efficient demand pageing.  The MH_EXECUTE, MH_FVMLIB, MH_DYLIB,
                     48:  * MH_DYLINKER and MH_BUNDLE file types also have the headers included as part
                     49:  * of their first segment.
                     50:  * 
                     51:  * The file type MH_OBJECT is a compact format intended as output of the
                     52:  * assembler and input (and possibly output) of the link editor (the .o
                     53:  * format).  All sections are in one unnamed segment with no segment padding. 
                     54:  * This format is used as an executable format when the file is so small the
                     55:  * segment padding greatly increases it's size.
                     56:  *
                     57:  * The file type MH_PRELOAD is an executable format intended for things that
                     58:  * not executed under the kernel (proms, stand alones, kernels, etc).  The
                     59:  * format can be executed under the kernel but may demand paged it and not
                     60:  * preload it before execution.
                     61:  *
                     62:  * A core file is in MH_CORE format and can be any in an arbritray legal
                     63:  * Mach-O file.
                     64:  *
                     65:  * Constants for the filetype field of the mach_header
                     66:  */
                     67: #define        MH_OBJECT       0x1             /* relocatable object file */
                     68: #define        MH_EXECUTE      0x2             /* demand paged executable file */
                     69: #define        MH_FVMLIB       0x3             /* fixed VM shared library file */
                     70: #define        MH_CORE         0x4             /* core file */
                     71: #define        MH_PRELOAD      0x5             /* preloaded executable file */
                     72: #define        MH_DYLIB        0x6             /* dynamicly bound shared library file*/
                     73: #define        MH_DYLINKER     0x7             /* dynamic link editor */
                     74: #define        MH_BUNDLE       0x8             /* dynamicly bound bundle file */
                     75: 
                     76: /* Constants for the flags field of the mach_header */
                     77: #define        MH_NOUNDEFS     0x1             /* the object file has no undefined
                     78:                                           references, can be executed */
                     79: #define        MH_INCRLINK     0x2             /* the object file is the output of an
                     80:                                           incremental link against a base file
                     81:                                           and can't be link edited again */
                     82: #define MH_DYLDLINK    0x4             /* the object file is input for the
                     83:                                           dynamic linker and can't be staticly
                     84:                                           link edited again */
                     85: 
                     86: /*
                     87:  * The load commands directly follow the mach_header.  The total size of all
                     88:  * of the commands is given by the sizeofcmds field in the mach_header.  All
                     89:  * load commands must have as their first two fields cmd and cmdsize.  The cmd
                     90:  * field is filled in with a constant for that command type.  Each command type
                     91:  * has a structure specifically for it.  The cmdsize field is the size in bytes
                     92:  * of the particular load command structure plus anything that follows it that
                     93:  * is a part of the load command (i.e. section structures, strings, etc.).  To
                     94:  * advance to the next load command the cmdsize can be added to the offset or
                     95:  * pointer of the current load command.  The cmdsize MUST be a multiple of
                     96:  * sizeof(long) (this is forever the maximum alignment of any load commands).
                     97:  * The padded bytes must be zero.  All tables in the object file must also
                     98:  * follow these rules so the file can be memory mapped.  Otherwise the pointers
                     99:  * to these tables will not work well or at all on some machines.  With all
                    100:  * padding zeroed like objects will compare byte for byte.
                    101:  */
                    102: struct load_command {
                    103:        unsigned long cmd;              /* type of load command */
                    104:        unsigned long cmdsize;          /* total size of command in bytes */
                    105: };
                    106: 
                    107: /* Constants for the cmd field of all load commands, the type */
                    108: #define        LC_SEGMENT      0x1     /* segment of this file to be mapped */
                    109: #define        LC_SYMTAB       0x2     /* link-edit stab symbol table info */
                    110: #define        LC_SYMSEG       0x3     /* link-edit gdb symbol table info (obsolete) */
                    111: #define        LC_THREAD       0x4     /* thread */
                    112: #define        LC_UNIXTHREAD   0x5     /* unix thread (includes a stack) */
                    113: #define        LC_LOADFVMLIB   0x6     /* load a specified fixed VM shared library */
                    114: #define        LC_IDFVMLIB     0x7     /* fixed VM shared library identification */
                    115: #define        LC_IDENT        0x8     /* object identification info (obsolete) */
                    116: #define LC_FVMFILE     0x9     /* fixed VM file inclusion (internal use) */
                    117: #define LC_PREPAGE      0xa     /* prepage command (internal use) */
                    118: #define        LC_DYSYMTAB     0xb     /* dynamic link-edit symbol table info */
                    119: #define        LC_LOAD_DYLIB   0xc     /* load a dynamicly linked shared library */
                    120: #define        LC_ID_DYLIB     0xd     /* dynamicly linked shared lib identification */
                    121: #define LC_LOAD_DYLINKER 0xe   /* load a dynamic linker */
                    122: #define LC_ID_DYLINKER 0xf     /* dynamic linker identification */
                    123: 
                    124: /*
                    125:  * A variable length string in a load command is represented by an lc_str
                    126:  * union.  The strings are stored just after the load command structure and
                    127:  * the offset is from the start of the load command structure.  The size
                    128:  * of the string is reflected in the cmdsize field of the load command.
                    129:  * Once again any padded bytes to bring the cmdsize field to a multiple
                    130:  * of sizeof(long) must be zero.
                    131:  */
                    132: union lc_str {
                    133:        unsigned long   offset; /* offset to the string */
                    134:        char            *ptr;   /* pointer to the string */
                    135: };
                    136: 
                    137: /*
                    138:  * The segment load command indicates that a part of this file is to be
                    139:  * mapped into the task's address space.  The size of this segment in memory,
                    140:  * vmsize, maybe equal to or larger than the amount to map from this file,
                    141:  * filesize.  The file is mapped starting at fileoff to the beginning of
                    142:  * the segment in memory, vmaddr.  The rest of the memory of the segment,
                    143:  * if any, is allocated zero fill on demand.  The segment's maximum virtual
                    144:  * memory protection and initial virtual memory protection are specified
                    145:  * by the maxprot and initprot fields.  If the segment has sections then the
                    146:  * section structures directly follow the segment command and their size is
                    147:  * reflected in cmdsize.
                    148:  */
                    149: struct segment_command {
                    150:        unsigned long   cmd;            /* LC_SEGMENT */
                    151:        unsigned long   cmdsize;        /* includes sizeof section structs */
                    152:        char            segname[16];    /* segment name */
                    153:        unsigned long   vmaddr;         /* memory address of this segment */
                    154:        unsigned long   vmsize;         /* memory size of this segment */
                    155:        unsigned long   fileoff;        /* file offset of this segment */
                    156:        unsigned long   filesize;       /* amount to map from the file */
                    157:        vm_prot_t       maxprot;        /* maximum VM protection */
                    158:        vm_prot_t       initprot;       /* initial VM protection */
                    159:        unsigned long   nsects;         /* number of sections in segment */
                    160:        unsigned long   flags;          /* flags */
                    161: };
                    162: 
                    163: /* Constants for the flags field of the segment_command */
                    164: #define        SG_HIGHVM       0x1     /* the file contents for this segment is for
                    165:                                   the high part of the VM space, the low part
                    166:                                   is zero filled (for stacks in core files) */
                    167: #define        SG_FVMLIB       0x2     /* this segment is the VM that is allocated by
                    168:                                   a fixed VM library, for overlap checking in
                    169:                                   the link editor */
                    170: #define        SG_NORELOC      0x4     /* this segment has nothing that was relocated
                    171:                                   in it and nothing relocated to it, that is
                    172:                                   it maybe safely replaced without relocation*/
                    173: 
                    174: /*
                    175:  * A segment is made up of zero or more sections.  Non-MH_OBJECT files have
                    176:  * all of their segments with the proper sections in each, and padded to the
                    177:  * specified segment alignment when produced by the link editor.  The first
                    178:  * segment of a MH_EXECUTE and MH_FVMLIB format file contains the mach_header
                    179:  * and load commands of the object file before it's first section.  The zero
                    180:  * fill sections are always last in their segment (in all formats).  This
                    181:  * allows the zeroed segment padding to be mapped into memory where zero fill
                    182:  * sections might be.
                    183:  *
                    184:  * The MH_OBJECT format has all of it's sections in one segment for
                    185:  * compactness.  There is no padding to a specified segment boundary and the
                    186:  * mach_header and load commands are not part of the segment.
                    187:  *
                    188:  * Sections with the same section name, sectname, going into the same segment,
                    189:  * segname, are combined by the link editor.  The resulting section is aligned
                    190:  * to the maximum alignment of the combined sections and is the new section's
                    191:  * alignment.  The combined sections are aligned to their original alignment in
                    192:  * the combined section.  Any padded bytes to get the specified alignment are
                    193:  * zeroed.
                    194:  *
                    195:  * The format of the relocation entries referenced by the reloff and nreloc
                    196:  * fields of the section structure for mach object files is described in the
                    197:  * header file <reloc.h>.
                    198:  */
                    199: struct section {
                    200:        char            sectname[16];   /* name of this section */
                    201:        char            segname[16];    /* segment this section goes in */
                    202:        unsigned long   addr;           /* memory address of this section */
                    203:        unsigned long   size;           /* size in bytes of this section */
                    204:        unsigned long   offset;         /* file offset of this section */
                    205:        unsigned long   align;          /* section alignment (power of 2) */
                    206:        unsigned long   reloff;         /* file offset of relocation entries */
                    207:        unsigned long   nreloc;         /* number of relocation entries */
                    208:        unsigned long   flags;          /* flags (section type and attributes)*/
                    209:        unsigned long   reserved1;      /* reserved */
                    210:        unsigned long   reserved2;      /* reserved */
                    211: };
                    212: 
                    213: /*
                    214:  * The flags field of a section structure is separated into two parts a section
                    215:  * type and section attributes.  The section types are mutually exclusive (it
                    216:  * can only have one type) but the section attributes are not (it may have more
                    217:  * than one attribute).
                    218:  */
                    219: #define SECTION_TYPE            0x000000ff     /* 256 section types */
                    220: #define SECTION_ATTRIBUTES      0xffffff00     /*  24 section attributes */
                    221: 
                    222: /* Constants for the type of a section */
                    223: #define        S_REGULAR               0x0     /* regular section */
                    224: #define        S_ZEROFILL              0x1     /* zero fill on demand section */
                    225: #define        S_CSTRING_LITERALS      0x2     /* section with only literal C strings*/
                    226: #define        S_4BYTE_LITERALS        0x3     /* section with only 4 byte literals */
                    227: #define        S_8BYTE_LITERALS        0x4     /* section with only 8 byte literals */
                    228: #define        S_LITERAL_POINTERS      0x5     /* section with only pointers to */
                    229:                                        /*  literals */
                    230: /*
                    231:  * For the two types of symbol pointers sections and the symbol stubs section
                    232:  * they have indirect symbol table entries.  For each of the entries in the
                    233:  * section the indirect symbol table entries, in corresponding order in the
                    234:  * indirect symbol table, start at the index stored in the reserved1 field
                    235:  * of the section structure.  Since the indirect symbol table entries
                    236:  * correspond to the entries in the section the number of indirect symbol table
                    237:  * entries is inferred from the size of the section divided by the size of the
                    238:  * entries in the section.  For symbol pointers sections the size of the entries
                    239:  * in the section is 4 bytes and for symbol stubs sections the byte size of the
                    240:  * stubs is stored in the reserved2 field of the section structure.
                    241:  */
                    242: #define        S_NON_LAZY_SYMBOL_POINTERS      0x6     /* section with only non-lazy
                    243:                                                   symbol pointers */
                    244: #define        S_LAZY_SYMBOL_POINTERS          0x7     /* section with only lazy symbol
                    245:                                                   pointers */
                    246: #define        S_SYMBOL_STUBS                  0x8     /* section with only symbol
                    247:                                                   stubs, byte size of stub in
                    248:                                                   the reserved2 field */
                    249: #define        S_MOD_INIT_FUNC_POINTERS        0x9     /* section with only function
                    250:                                                   pointers for initialization*/
                    251: /*
                    252:  * Constants for the section attributes part of the flags field of a section
                    253:  * structure.
                    254:  */
                    255: #define S_ATTR_PURE_INSTRUCTIONS 0x80000000    /* section contains only true
                    256:                                                   machine instructions */
                    257: #define S_ATTR_RELOC_AT_LAUNCH  0x40000000     /* section is to be relocate
                    258:                                                   at launch time */
                    259: #define S_ATTR_EXT_RELOC        0x00000200     /* section has external
                    260:                                                   relocation entries */
                    261: #define S_ATTR_LOC_RELOC        0x00000100     /* section has local
                    262:                                                   relocation entries */
                    263: 
                    264: 
                    265: /*
                    266:  * The names of segments and sections in them are mostly meaningless to the
                    267:  * link-editor.  But there are few things to support traditional UNIX
                    268:  * executables that require the link-editor and assembler to use some names
                    269:  * agreed upon by convention.
                    270:  *
                    271:  * The initial protection of the "__TEXT" segment has write protection turned
                    272:  * off (not writeable).
                    273:  *
                    274:  * The link-editor will allocate common symbols at the end of the "__common"
                    275:  * section in the "__DATA" segment.  It will create the section and segment
                    276:  * if needed.
                    277:  */
                    278: 
                    279: /* The currently known segment names and the section names in those segments */
                    280: 
                    281: #define        SEG_PAGEZERO    "__PAGEZERO"    /* the pagezero segment which has no */
                    282:                                        /* protections and catches NULL */
                    283:                                        /* references for MH_EXECUTE files */
                    284: 
                    285: 
                    286: #define        SEG_TEXT        "__TEXT"        /* the tradition UNIX text segment */
                    287: #define        SECT_TEXT       "__text"        /* the real text part of the text */
                    288:                                        /* section no headers, and no padding */
                    289: #define SECT_FVMLIB_INIT0 "__fvmlib_init0"     /* the fvmlib initialization */
                    290:                                                /*  section */
                    291: #define SECT_FVMLIB_INIT1 "__fvmlib_init1"     /* the section following the */
                    292:                                                /*  fvmlib initialization */
                    293:                                                /*  section */
                    294: 
                    295: #define        SEG_DATA        "__DATA"        /* the tradition UNIX data segment */
                    296: #define        SECT_DATA       "__data"        /* the real initialized data section */
                    297:                                        /* no padding, no bss overlap */
                    298: #define        SECT_BSS        "__bss"         /* the real uninitialized data section*/
                    299:                                        /* no padding */
                    300: #define SECT_COMMON    "__common"      /* the section common symbols are */
                    301:                                        /* allocated in by the link editor */
                    302: 
                    303: #define        SEG_OBJC        "__OBJC"        /* objective-C runtime segment */
                    304: #define SECT_OBJC_SYMBOLS "__symbol_table"     /* symbol table */
                    305: #define SECT_OBJC_MODULES "__module_info"      /* module information */
                    306: #define SECT_OBJC_STRINGS "__selector_strs"    /* string table */
                    307: #define SECT_OBJC_REFS "__selector_refs"       /* string table */
                    308: 
                    309: #define        SEG_ICON         "__ICON"       /* the NeXT icon segment */
                    310: #define        SECT_ICON_HEADER "__header"     /* the icon headers */
                    311: #define        SECT_ICON_TIFF   "__tiff"       /* the icons in tiff format */
                    312: 
                    313: #define        SEG_LINKEDIT    "__LINKEDIT"    /* the segment containing all structs */
                    314:                                        /* created and maintained by the link */
                    315:                                        /* editor.  Created with -seglinkedit */
                    316:                                        /* option to ld(1) for MH_EXECUTE and */
                    317:                                        /* FVMLIB file types only */
                    318: /*
                    319:  * Fixed virtual memory shared libraries are identified by two things.  The
                    320:  * target pathname (the name of the library as found for execution), and the
                    321:  * minor version number.  The address of where the headers are loaded is in
                    322:  * header_addr.
                    323:  */
                    324: struct fvmlib {
                    325:        union lc_str    name;           /* library's target pathname */
                    326:        unsigned long   minor_version;  /* library's minor version number */
                    327:        unsigned long   header_addr;    /* library's header address */
                    328: };
                    329: 
                    330: /*
                    331:  * A fixed virtual shared library (filetype == MH_FVMLIB in the mach header)
                    332:  * contains a fvmlib_command (cmd == LC_IDFVMLIB) to identify the library.
                    333:  * An object that uses a fixed virtual shared library also contains a
                    334:  * fvmlib_command (cmd == LC_LOADFVMLIB) for each library it uses.
                    335:  */
                    336: struct fvmlib_command {
                    337:        unsigned long   cmd;            /* LC_IDFVMLIB or LC_LOADFVMLIB */
                    338:        unsigned long   cmdsize;        /* includes pathname string */
                    339:        struct fvmlib   fvmlib;         /* the library identification */
                    340: };
                    341: 
                    342: /*
                    343:  * Dynamicly linked shared libraries are identified by two things.  The
                    344:  * pathname (the name of the library as found for execution), and the
                    345:  * compatibility version number.  The pathname must match and the compatibility
                    346:  * number in the user of the library must be greater than or equal to the
                    347:  * library being used.  The time stamp is used to record the time a library was
                    348:  * built and copied into user so it can be use to determined if the library used
                    349:  * at runtime is exactly the same as used to built the program.
                    350:  */
                    351: struct dylib {
                    352:     union lc_str  name;                        /* library's path name */
                    353:     unsigned long timestamp;           /* library's build time stamp */
                    354:     unsigned long current_version;     /* library's current version number */
                    355:     unsigned long compatibility_version;/* library's compatibility vers number*/
                    356: };
                    357: 
                    358: /*
                    359:  * A dynamicly linked shared library (filetype == MH_DYLIB in the mach header)
                    360:  * contains a dylib_command (cmd == LC_ID_DYLIB) to identify the library.
                    361:  * An object that uses a dynamicly linked shared library also contains a
                    362:  * dylib_command (cmd == LC_LOAD_DYLIB) for each library it uses.
                    363:  */
                    364: struct dylib_command {
                    365:        unsigned long   cmd;            /* LC_ID_DYLIB or LC_LOAD_DYLIB */
                    366:        unsigned long   cmdsize;        /* includes pathname string */
                    367:        struct dylib    dylib;          /* the library identification */
                    368: };
                    369: 
                    370: /*
                    371:  * A program that uses a dynamic linker contains a dylinker_command to identify
                    372:  * the name of the dynamic linker (LC_LOAD_DYLINKER).  And a dynamic linker
                    373:  * contains a dylinker_command to identify the dynamic linker (LC_ID_DYLINKER).
                    374:  * A file can have at most one of these.
                    375:  */
                    376: struct dylinker_command {
                    377:        unsigned long   cmd;            /* LC_ID_DYLINKER or LC_LOAD_DYLINKER */
                    378:        unsigned long   cmdsize;        /* includes pathname string */
                    379:        union lc_str    name;           /* dynamic linker's path name */
                    380: };
                    381: 
                    382: /*
                    383:  * Thread commands contain machine-specific data structures suitable for
                    384:  * use in the thread state primitives.  The machine specific data structures
                    385:  * follow the struct thread_command as follows.
                    386:  * Each flavor of machine specific data structure is preceded by an unsigned
                    387:  * long constant for the flavor of that data structure, an unsigned long
                    388:  * that is the count of longs of the size of the state data structure and then
                    389:  * the state data structure follows.  This triple may be repeated for many
                    390:  * flavors.  The constants for the flavors, counts and state data structure
                    391:  * definitions are expected to be in the header file <machine/thread_status.h>.
                    392:  * These machine specific data structures sizes must be multiples of
                    393:  * sizeof(long).  The cmdsize reflects the total size of the thread_command
                    394:  * and all of the sizes of the constants for the flavors, counts and state
                    395:  * data structures.
                    396:  *
                    397:  * For executable objects that are unix processes there will be one
                    398:  * thread_command (cmd == LC_UNIXTHREAD) created for it by the link-editor.
                    399:  * This is the same as a LC_THREAD, except that a stack is automatically
                    400:  * created (based on the shell's limit for the stack size).  Command arguments
                    401:  * and environment variables are copied onto that stack.
                    402:  */
                    403: struct thread_command {
                    404:        unsigned long   cmd;            /* LC_THREAD or  LC_UNIXTHREAD */
                    405:        unsigned long   cmdsize;        /* total size of this command */
                    406:        /* unsigned long flavor            flavor of thread state */
                    407:        /* unsigned long count             count of longs in thread state */
                    408:        /* struct XXX_thread_state state   thread state for this flavor */
                    409:        /* ... */
                    410: };
                    411: 
                    412: /*
                    413:  * The symtab_command contains the offsets and sizes of the link-edit 4.3BSD
                    414:  * "stab" style symbol table information as described in the header files
                    415:  * <nlist.h> and <stab.h>.
                    416:  */
                    417: struct symtab_command {
                    418:        unsigned long   cmd;            /* LC_SYMTAB */
                    419:        unsigned long   cmdsize;        /* sizeof(struct symtab_command) */
                    420:        unsigned long   symoff;         /* symbol table offset */
                    421:        unsigned long   nsyms;          /* number of symbol table entries */
                    422:        unsigned long   stroff;         /* string table offset */
                    423:        unsigned long   strsize;        /* string table size in bytes */
                    424: };
                    425: 
                    426: /*
                    427:  * This is the second set of the symbolic information which is used to support
                    428:  * the data structures for the dynamicly link editor.
                    429:  *
                    430:  * The original set of symbolic information in the symtab_command which contains
                    431:  * the symbol and string tables must also be present when this load command is
                    432:  * present.  When this load command is present the symbol table is organized
                    433:  * into three groups of symbols:
                    434:  *     local symbols (static and debugging symbols) - grouped by module
                    435:  *     defined external symbols - grouped by module (sorted by name if not lib)
                    436:  *     undefined external symbols (sorted by name)
                    437:  * In this load command there are offsets and counts to each of the three groups
                    438:  * of symbols.
                    439:  *
                    440:  * This load command contains a the offsets and sizes of the following new
                    441:  * symbolic information tables:
                    442:  *     table of contents
                    443:  *     module table
                    444:  *     reference symbol table
                    445:  *     indirect symbol table
                    446:  * The first three tables above (the table of contents, module table and
                    447:  * reference symbol table) are only present if the file is a dynamicly linked
                    448:  * shared library.  For executable and object modules, which are files
                    449:  * containing only one module, the information that would be in these three
                    450:  * tables is determined as follows:
                    451:  *     table of contents - the defined external symbols are sorted by name
                    452:  *     module table - the file contains only one module so everything in the
                    453:  *                    file is part of the module.
                    454:  *     reference symbol table - is the defined and undefined external symbols
                    455:  *
                    456:  * For dynamicly linked shared library files this load command also contains
                    457:  * offsets and sizes to the pool of relocation entries for all sections
                    458:  * separated into two groups:
                    459:  *     external relocation entries
                    460:  *     local relocation entries
                    461:  * For executable and object modules the relocation entries continue to hang
                    462:  * off the section structures.
                    463:  */
                    464: struct dysymtab_command {
                    465:     unsigned long cmd;         /* LC_DYSYMTAB */
                    466:     unsigned long cmdsize;     /* sizeof(struct dysymtab_command) */
                    467: 
                    468:     /*
                    469:      * The symbols indicated by symoff and nsyms of the LC_SYMTAB load command
                    470:      * are grouped into the following three groups:
                    471:      *    local symbols (further grouped by the module they are from)
                    472:      *    defined external symbols (further grouped by the module they are from)
                    473:      *    undefined symbols
                    474:      *
                    475:      * The local symbols are used only for debugging.  The dynamic binding
                    476:      * process may have to use them to indicate to the debugger the local
                    477:      * symbols for a module that is being bound.
                    478:      *
                    479:      * The last two groups are used by the dynamic binding process to do the
                    480:      * binding (indirectly through the module table and the reference symbol
                    481:      * table when this is a dynamicly linked shared library file).
                    482:      */
                    483:     unsigned long ilocalsym;   /* index to local symbols */
                    484:     unsigned long nlocalsym;   /* number of local symbols */
                    485: 
                    486:     unsigned long iextdefsym;  /* index to externally defined symbols */
                    487:     unsigned long nextdefsym;  /* number of externally defined symbols */
                    488: 
                    489:     unsigned long iundefsym;   /* index to undefined symbols */
                    490:     unsigned long nundefsym;   /* number of undefined symbols */
                    491: 
                    492:     /*
                    493:      * For the for the dynamic binding process to find which module a symbol
                    494:      * is defined in the table of contents is used (analogous to the ranlib
                    495:      * structure in an archive) which maps defined external symbols to modules
                    496:      * they are defined in.  This exists only in a dynamicly linked shared
                    497:      * library file.  For executable and object modules the defined external
                    498:      * symbols are sorted by name and is use as the table of contents.
                    499:      */
                    500:     unsigned long tocoff;      /* file offset to table of contents */
                    501:     unsigned long ntoc;                /* number of entries in table of contents */
                    502: 
                    503:     /*
                    504:      * To support dynamic binding of "modules" (whole object files) the symbol
                    505:      * table must reflect the modules that the file was created from.  This is
                    506:      * done by having a module table that has indexes and counts into the merged
                    507:      * tables for each module.  The module structure that these two entries
                    508:      * refer to is described below.  This exists only in a dynamicly linked
                    509:      * shared library file.  For executable and object modules the file only
                    510:      * contains one module so everything in the file belongs to the module.
                    511:      */
                    512:     unsigned long modtaboff;   /* file offset to module table */
                    513:     unsigned long nmodtab;     /* number of module table entries */
                    514: 
                    515:     /*
                    516:      * To support dynamic module binding the module structure for each module
                    517:      * indicates the external references (defined and undefined) each module
                    518:      * makes.  For each module there is an offset and a count into the
                    519:      * reference symbol table for the symbols that the module references.
                    520:      * This exists only in a dynamicly linked shared library file.  For
                    521:      * executable and object modules the defined external symbols and the
                    522:      * undefined external symbols indicates the external references.
                    523:      */
                    524:     unsigned long extrefsymoff;  /* offset to referenced symbol table */
                    525:     unsigned long nextrefsyms;  /* number of referenced symbol table entries */
                    526: 
                    527:     /*
                    528:      * The sections that contain "symbol pointers" and "routine stubs" have
                    529:      * indexes and (implied counts based on the size of the section and fixed
                    530:      * size of the entry) into the "indirect symbol" table for each pointer
                    531:      * and stub.  For every section of these two types the index into the
                    532:      * indirect symbol table is stored in the section header in the field
                    533:      * reserved1.  An indirect symbol table entry is simply a 32bit index into
                    534:      * the symbol table to the symbol that the pointer or stub is referring to.
                    535:      * The indirect symbol table is ordered to match the entries in the section.
                    536:      */
                    537:     unsigned long indirectsymoff; /* file offset to the indirect symbol table */
                    538:     unsigned long nindirectsyms;  /* number of indirect symbol table entries */
                    539: 
                    540:     /*
                    541:      * To support relocating an individual module in a library file quickly the
                    542:      * external relocation entries for each module in the library need to be
                    543:      * accessed efficiently.  Since the relocation entries can't be accessed
                    544:      * through the section headers for a library file they are separated into
                    545:      * groups of local and external entries further grouped by module.  In this
                    546:      * case the presents of this load command who's extreloff, nextrel,
                    547:      * locreloff and nlocrel fields are non-zero indicates that the relocation
                    548:      * entries of non-merged sections are not referenced through the section
                    549:      * structures (and the reloff and nreloc fields in the section headers are
                    550:      * set to zero).
                    551:      *
                    552:      * Since the relocation entries are not accessed through the section headers
                    553:      * this requires the r_address field to be something other than a section
                    554:      * offset to identify the item to be relocated.  In this case r_address is
                    555:      * set to the offset from the vmaddr of the first LC_SEGMENT command.
                    556:      *
                    557:      * The relocation entries are grouped by module and the module table
                    558:      * entries have indexes and counts into them for the group of external
                    559:      * relocation entries for that the module.
                    560:      *
                    561:      * For sections that are merged across modules there must not be any
                    562:      * remaining external relocation entries for them (for merged sections
                    563:      * remaining relocation entries must be local).
                    564:      */
                    565:     unsigned long extreloff;   /* offset to external relocation entries */
                    566:     unsigned long nextrel;     /* number of external relocation entries */
                    567: 
                    568:     /*
                    569:      * All the local relocation entries are grouped together (they are not
                    570:      * grouped by their module since they are only used if the object is moved
                    571:      * from it staticly link edited address).
                    572:      */
                    573:     unsigned long locreloff;   /* offset to local relocation entries */
                    574:     unsigned long nlocrel;     /* number of local relocation entries */
                    575: 
                    576: };     
                    577: 
                    578: /* a table of contents entry */
                    579: struct dylib_table_of_contents {
                    580:     unsigned long symbol_index;        /* the defined external symbol
                    581:                                   (index into the symbol table) */
                    582:     unsigned long module_index;        /* index into the module table this symbol
                    583:                                   is defined in */
                    584: };     
                    585: 
                    586: /* a module table entry */
                    587: struct dylib_module {
                    588:     unsigned long module_name; /* the module name (index into string table) */
                    589: 
                    590:     unsigned long iextdefsym;  /* index into externally defined symbols */
                    591:     unsigned long nextdefsym;  /* number of externally defined symbols */
                    592:     unsigned long irefsym;             /* index into reference symbol table */
                    593:     unsigned long nrefsym;     /* number of reference symbol table entries */
                    594:     unsigned long ilocalsym;   /* index into symbols for local symbols */
                    595:     unsigned long nlocalsym;   /* number of local symbols */
                    596: 
                    597:     unsigned long iextrel;     /* index into external relocation entries */
                    598:     unsigned long nextrel;     /* number of external relocation entries */
                    599: 
                    600:     unsigned long iinit;       /* index into the init section */
                    601:     unsigned long ninit;       /* number of init section entries */
                    602: 
                    603:     unsigned long              /* for this module address of the start of */
                    604:        objc_module_info_addr;  /*  the (__OBJC,__module_info) section */
                    605:     unsigned long              /* for this module address of the size of */
                    606:        objc_module_info_size;  /*  the (__OBJC,__module_info) section */
                    607: };     
                    608: 
                    609: /* 
                    610:  * The entries in the reference symbol table are used when loading the module
                    611:  * (both by the static and dynamic link editors) and if the module is unloaded
                    612:  * or replaced.  Therefore all external symbols (defined and undefined) are
                    613:  * listed in the module's reference table.  The flags describe the type of
                    614:  * reference that is being made.  The constants for the flags are defined in
                    615:  * <mach-o/nlist.h> as they are also used for symbol table entries.
                    616:  */
                    617: struct dylib_reference {
                    618:     unsigned long isym:24,     /* index into the symbol table */
                    619:                  flags:8;      /* flags to indicate the type of reference */
                    620: };
                    621: 
                    622: /*
                    623:  * The symseg_command contains the offset and size of the GNU style
                    624:  * symbol table information as described in the header file <symseg.h>.
                    625:  * The symbol roots of the symbol segments must also be aligned properly
                    626:  * in the file.  So the requirement of keeping the offsets aligned to a
                    627:  * multiple of a sizeof(long) translates to the length field of the symbol
                    628:  * roots also being a multiple of a long.  Also the padding must again be
                    629:  * zeroed. (THIS IS OBSOLETE and no longer supported).
                    630:  */
                    631: struct symseg_command {
                    632:        unsigned long   cmd;            /* LC_SYMSEG */
                    633:        unsigned long   cmdsize;        /* sizeof(struct symseg_command) */
                    634:        unsigned long   offset;         /* symbol segment offset */
                    635:        unsigned long   size;           /* symbol segment size in bytes */
                    636: };
                    637: 
                    638: /*
                    639:  * The ident_command contains a free format string table following the
                    640:  * ident_command structure.  The strings are null terminated and the size of
                    641:  * the command is padded out with zero bytes to a multiple of sizeof(long).
                    642:  * (THIS IS OBSOLETE and no longer supported).
                    643:  */
                    644: struct ident_command {
                    645:        unsigned long cmd;              /* LC_IDENT */
                    646:        unsigned long cmdsize;          /* strings that follow this command */
                    647: };
                    648: 
                    649: /*
                    650:  * The fvmfile_command contains a reference to a file to be loaded at the
                    651:  * specified virtual address.  (Presently, this command is reserved for NeXT
                    652:  * internal use.  The kernel ignores this command when loading a program into
                    653:  * memory).
                    654:  */
                    655: struct fvmfile_command {
                    656:        unsigned long cmd;              /* LC_FVMFILE */
                    657:        unsigned long cmdsize;          /* includes pathname string */
                    658:        union lc_str    name;           /* files pathname */
                    659:        unsigned long   header_addr;    /* files virtual address */
                    660: };
                    661: 
                    662: #endif _MACHO_LOADER_H_

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.