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