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