home *** CD-ROM | disk | FTP | other *** search
/ NeXTSTEP 3.2 (Developer) / NS_dev_3.2.iso / NextDeveloper / Headers / mach-o / loader.h < prev    next >
Text File  |  1993-10-19  |  16KB  |  371 lines
  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.  Both the MH_EXECUTE and the
  48.  * MH_FVMLIB file types also have the headers included as part of their first
  49.  * 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 leagal
  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.  
  73. /* Constants for the flags field of the mach_header */
  74. #define    MH_NOUNDEFS    0x1        /* the object file has no undefined
  75.                        references, can be executed */
  76. #define    MH_INCRLINK    0x2        /* the object file is the output of an
  77.                        incremental link against a base file
  78.                        and can't be link edited again */
  79.  
  80. /*
  81.  * The load commands directly follow the mach_header.  The total size of all
  82.  * of the commands is given by the sizeofcmds field in the mach_header.  All
  83.  * load commands must have as their first two fields cmd and cmdsize.  The cmd
  84.  * field is filled in with a constant for that command type.  Each command type
  85.  * has a structure specifically for it.  The cmdsize field is the size in bytes
  86.  * of the particular load command structure plus anything that follows it that
  87.  * is a part of the load command (i.e. section structures, strings, etc.).  To
  88.  * advance to the next load command the cmdsize can be added to the offset or
  89.  * pointer of the current load command.  The cmdsize MUST be a multiple of
  90.  * sizeof(long) (this is forever the maximum alignment of any load commands).
  91.  * The padded bytes must be zero.  All tables in the object file must also
  92.  * follow these rules so the file can be memory mapped.  Otherwise the pointers
  93.  * to these tables will not work well or at all on some machines.  With all
  94.  * padding zeroed like objects will compare byte for byte.
  95.  */
  96. struct load_command {
  97.     unsigned long cmd;        // type of load command
  98.     unsigned long cmdsize;        // total size of command in bytes
  99. };
  100.  
  101. /* Constants for the cmd field of all load commands, the type */
  102. #define    LC_SEGMENT    0x1    // segment of this file to be mapped
  103. #define    LC_SYMTAB    0x2    // link-edit stab symbol table info
  104. #define    LC_SYMSEG    0x3    // link-edit gdb symbol table info (obsolete)
  105. #define    LC_THREAD    0x4    // thread
  106. #define    LC_UNIXTHREAD    0x5    // unix thread (includes a stack)
  107. #define    LC_LOADFVMLIB    0x6    // load a specified fixed VM shared library
  108. #define    LC_IDFVMLIB    0x7    // fixed VM shared library identification
  109. #define    LC_IDENT    0x8    // object identification information (obsolete)
  110. #define LC_FVMFILE    0x9    // fixed VM file inclusion
  111. #define LC_PREPAGE      0xa     // prepage command (internal use)
  112.  
  113. /*
  114.  * A variable length string in a load command is represented by an lc_str
  115.  * union.  The strings are stored just after the load command structure and
  116.  * the offset is from the start of the load command structure.  The size
  117.  * of the string is reflected in the cmdsize field of the load command.
  118.  * Once again any padded bytes to bring the cmdsize field to a multiple
  119.  * of sizeof(long) must be zero.
  120.  */
  121. union lc_str {
  122.     unsigned long    offset;    /* offset to the string */
  123.     char        *ptr;    /* pointer to the string */
  124. };
  125.  
  126. /*
  127.  * The segment load command indicates that a part of this file is to be
  128.  * mapped into the task's address space.  The size of this segment in memory,
  129.  * vmsize, maybe equal to or larger than the amount to map from this file,
  130.  * filesize.  The file is mapped starting at fileoff to the beginning of
  131.  * the segment in memory, vmaddr.  The rest of the memory of the segment,
  132.  * if any, is allocated zero fill on demand.  The segment's maximum virtual
  133.  * memory protection and initial virtual memory protection are specified
  134.  * by the maxprot and initprot fields.  If the segment has sections then the
  135.  * section structures directly follow the segment command and their size is
  136.  * reflected in cmdsize.
  137.  */
  138. struct segment_command {
  139.     unsigned long    cmd;        // LC_SEGMENT
  140.     unsigned long    cmdsize;    // includes sizeof section structs
  141.     char        segname[16];    // segment name
  142.     unsigned long    vmaddr;        // memory address of this segment
  143.     unsigned long    vmsize;        // memory size of this segment
  144.     unsigned long    fileoff;    // file offset of this segment
  145.     unsigned long    filesize;    // amount to map from the file
  146.     vm_prot_t    maxprot;    // maximum VM protection
  147.     vm_prot_t    initprot;    // initial VM protection
  148.     unsigned long    nsects;        // number of sections in segment
  149.     unsigned long    flags;        // flags
  150. };
  151.  
  152. /* Constants for the flags field of the segment_command */
  153. #define    SG_HIGHVM    0x1    // the file contents for this segment is for
  154.                 // the high part of the VM space, the low part
  155.                 // is zero filled (for stacks in core files)
  156. #define    SG_FVMLIB    0x2    // this segment is the VM that is allocated by
  157.                 // a fixed VM library, for overlap checking in
  158.                 // the link editor
  159. #define    SG_NORELOC    0x4    // this segment has nothing that was relocated
  160.                 // in it and nothing relocated to it, that is
  161.                 // it maybe safely replaced without relocation
  162.  
  163. /*
  164.  * A segment is made up of zero or more sections.  Non-MH_OBJECT files have
  165.  * all of their segments with the proper sections in each, and padded to the
  166.  * specified segment alignment when produced by the link editor.  The first
  167.  * segment of a MH_EXECUTE and MH_FVMLIB format file contains the mach_header
  168.  * and load commands of the object file before it's first section.  The zero
  169.  * fill sections are always last in their segment (in all formats).  This
  170.  * allows the zeroed segment padding to be mapped into memory where zero fill
  171.  * sections might be.
  172.  *
  173.  * The MH_OBJECT format has all of it's sections in one segment for
  174.  * compactness.  There is no padding to a specified segment boundary and the
  175.  * mach_header and load commands are not part of the segment.
  176.  *
  177.  * Sections with the same section name, sectname, going into the same segment,
  178.  * segname, are combined by the link editor.  The resulting section is aligned
  179.  * to the maximum alignment of the combined sections and is the new section's
  180.  * alignment.  The combined sections are aligned to their original alignment in
  181.  * the combined section.  Any padded bytes to get the specified alignment are
  182.  * zeroed.
  183.  *
  184.  * The format of the relocation entries referenced by the reloff and nreloc
  185.  * fields of the section structure for mach object files is described in the
  186.  * header file <reloc.h>.
  187.  */
  188. struct section {
  189.     char        sectname[16];    // name of this section
  190.     char        segname[16];    // segment this section goes in
  191.     unsigned long    addr;        // memory address of this section
  192.     unsigned long    size;        // size in bytes of this section
  193.     unsigned long    offset;        // file offset of this section
  194.     unsigned long    align;        // section alignment (power of 2)
  195.     unsigned long    reloff;        // file offset of relocation entries
  196.     unsigned long    nreloc;        // number of relocation entries
  197.     unsigned long    flags;        // flags (i.e. zero fill section, etc)
  198.     unsigned long    reserved1;    // reserved
  199.     unsigned long    reserved2;    // reserved
  200. };
  201. /* Constants for the flags field of a section structure */
  202. #define    S_ZEROFILL        0x1    // zero fill on demand section
  203. #define    S_CSTRING_LITERALS    0x2    // section with only literal C strings
  204. #define    S_4BYTE_LITERALS    0x3    // section with only 4 byte literals
  205. #define    S_8BYTE_LITERALS    0x4    // section with only 8 byte literals
  206. #define    S_LITERAL_POINTERS    0x5    // section with only pointers to
  207.                     //  literals
  208.  
  209. /*
  210.  * The names of segments and sections in them are mostly meaningless to the
  211.  * link-editor.  But there are few things to support traditional UNIX
  212.  * executables that require the link-editor and assembler to use some names
  213.  * agreed upon by convention.
  214.  *
  215.  * The initial protection of the "__TEXT" segment has write protection turned
  216.  * off (not writeable).
  217.  *
  218.  * The link-editor will allocate common symbols at the end of the "__common"
  219.  * section in the "__DATA" segment.  It will create the section and segment
  220.  * if needed.
  221.  */
  222.  
  223. /* The currently known segment names and the section names in those segments */
  224.  
  225. #define    SEG_PAGEZERO    "__PAGEZERO"    // the pagezero segment which has no
  226.                     // protections and catches NULL
  227.                     // references for MH_EXECUTE files
  228.  
  229.  
  230. #define    SEG_TEXT    "__TEXT"    // the tradition UNIX text segment
  231. #define    SECT_TEXT    "__text"    // the real text part of the text
  232.                     // section no headers, and no padding
  233. #define SECT_FVMLIB_INIT0 "__fvmlib_init0"    // the fvmlib initialization
  234.                         //  section
  235. #define SECT_FVMLIB_INIT1 "__fvmlib_init1"    // the section following the
  236.                             //  fvmlib initialization
  237.                         //  section
  238.  
  239. #define    SEG_DATA    "__DATA"    // the tradition UNIX data segment
  240. #define    SECT_DATA    "__data"    // the real initialized data section
  241.                     // no padding, no bss overlap
  242. #define    SECT_BSS    "__bss"        // the real uninitialized data section
  243.                     // no padding
  244. #define SECT_COMMON    "__common"    // the section common symbols are allo-
  245.                     // cated in by the link editor
  246.  
  247. #define    SEG_OBJC    "__OBJC"    // objective-C runtime segment
  248. #define SECT_OBJC_SYMBOLS "__symbol_table"    // symbol table
  249. #define SECT_OBJC_MODULES "__module_info"    // module information
  250. #define SECT_OBJC_STRINGS "__selector_strs"    // string table
  251. #define SECT_OBJC_REFS "__selector_refs"    // string table
  252.  
  253. #define    SEG_ICON     "__ICON"    // the NeXT icon segment
  254. #define    SECT_ICON_HEADER "__header"    // the icon headers
  255. #define    SECT_ICON_TIFF   "__tiff"    // the icons in tiff format
  256.  
  257. #define    SEG_LINKEDIT    "__LINKEDIT"    // the segment containing all
  258.                     // structures created and maintained by
  259.                     // the link editor.  Created with 
  260.                     // -seglinkedit option to ld(1) for
  261.                     // MH_EXECUTE and FVMLIB file types 
  262.                     // only
  263. /*
  264.  * Fixed virtual memory shared libraries are identified by two things.  The
  265.  * target pathname (the name of the library as found for execution), and the
  266.  * minor version number.  The address of where the headers are loaded is in
  267.  * header_addr.
  268.  */
  269. struct fvmlib {
  270.     union lc_str    name;        // library's target pathname
  271.     unsigned long    minor_version;    // library's minor version number
  272.     unsigned long    header_addr;    // library's header address
  273. };
  274.  
  275. /*
  276.  * A fixed virtual shared library (filetype == MH_FVMLIB in the mach header)
  277.  * contains a fvmlib_command (cmd == LC_IDFVMLIB) to identify the library.
  278.  * An object that uses a fixed virtual shared library also contains a
  279.  * fvmlib_command (cmd == LC_LOADFVMLIB) for each library it uses.
  280.  */
  281. struct fvmlib_command {
  282.     unsigned long    cmd;        // LC_IDFVMLIB or LC_LOADFVMLIB
  283.     unsigned long    cmdsize;    // includes pathname string
  284.     struct fvmlib    fvmlib;        // the library identification
  285. };
  286.  
  287. /*
  288.  * Thread commands contain machine-specific data structures suitable for
  289.  * use in the thread state primitives.  The machine specific data structures
  290.  * follow the struct thread_command as follows.
  291.  * Each flavor of machine specific data structure is preceded by an unsigned
  292.  * long constant for the flavor of that data structure, an unsigned long
  293.  * that is the count of longs of the size of the state data structure and then
  294.  * the state data structure follows.  This triple may be repeated for many
  295.  * flavors.  The constants for the flavors, counts and state data structure
  296.  * definitions are expected to be in the header file <machine/thread_status.h>.
  297.  * These machine specific data structures sizes must be multiples of
  298.  * sizeof(long).  The cmdsize reflects the total size of the thread_command
  299.  * and all of the sizes of the constants for the flavors, counts and state
  300.  * data structures.
  301.  *
  302.  * For executable objects that are unix processes there will be one
  303.  * thread_command (cmd == LC_UNIXTHREAD) created for it by the link-editor.
  304.  * This is the same as a LC_THREAD, except that a stack is automatically
  305.  * created (based on the shell's limit for the stack size).  Command arguments
  306.  * and environment variables are copied onto that stack.
  307.  */
  308. struct thread_command {
  309.     unsigned long    cmd;        // LC_THREAD or  LC_UNIXTHREAD
  310.     unsigned long    cmdsize;    // total size of this command
  311.     // unsigned long flavor           flavor of thread state
  312.     // unsigned long count           count of longs in thread state
  313.     // struct XXX_thread_state state   thread state for this flavor
  314.     // ...
  315. };
  316.  
  317. /*
  318.  * The symtab_command contains the offsets and sizes of the link-edit 4.3BSD
  319.  * "stab" style symbol table information as described in the header files
  320.  * <nlist.h> and <stab.h>.
  321.  */
  322. struct symtab_command {
  323.     unsigned long    cmd;        // LC_SYMTAB
  324.     unsigned long    cmdsize;    // sizeof(struct symtab_command)
  325.     unsigned long    symoff;        // symbol table offset
  326.     unsigned long    nsyms;        // number of symbol table entries
  327.     unsigned long    stroff;        // string table offset
  328.     unsigned long    strsize;    // string table size in bytes
  329. };
  330.  
  331. /*
  332.  * The symseg_command contains the offset and size of the GNU style
  333.  * symbol table information as described in the header file <symseg.h>.
  334.  * The symbol roots of the symbol segments must also be aligned properly
  335.  * in the file.  So the requirement of keeping the offsets aligned to a
  336.  * multiple of a sizeof(long) translates to the length field of the symbol
  337.  * roots also being a multiple of a long.  Also the padding must again be
  338.  * zeroed. (THIS IS OBSOLETE and no longer supported).
  339.  */
  340. struct symseg_command {
  341.     unsigned long    cmd;        // LC_SYMSEG
  342.     unsigned long    cmdsize;    // sizeof(struct symseg_command)
  343.     unsigned long    offset;        // symbol segment offset
  344.     unsigned long    size;        // symbol segment size in bytes
  345. };
  346.  
  347. /*
  348.  * The ident_command contains a free format string table following the
  349.  * ident_command structure.  The strings are null terminated and the size of
  350.  * the command is padded out with zero bytes to a multiple of sizeof(long).
  351.  * (THIS IS OBSOLETE and no longer supported).
  352.  */
  353. struct ident_command {
  354.     unsigned long cmd;        // LC_IDENT
  355.     unsigned long cmdsize;        // strings that follow this command
  356. };
  357.  
  358. /*
  359.  * The fvmfile_command contains a reference to a file to be loaded at the
  360.  * specified virtual address.  (Presently, this command is reserved for NeXT
  361.  * internal use.  The kernel ignores this command when loading a program into
  362.  * memory).
  363.  */
  364. struct fvmfile_command {
  365.     unsigned long cmd;        // LC_FVMFILE
  366.     unsigned long cmdsize;        // includes pathname string
  367.     union lc_str    name;        // files pathname
  368.     unsigned long    header_addr;    // files virtual address
  369. };
  370. #endif _MACHO_LOADER_H_
  371.