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