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