1 | /*␊ |
2 | * Copyright (c) 1999 Apple Computer, Inc. All rights reserved.␊ |
3 | *␊ |
4 | * @APPLE_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. Please obtain a copy of the License at␊ |
10 | * http://www.opensource.apple.com/apsl/ and read it before using this␊ |
11 | * file.␊ |
12 | * ␊ |
13 | * The Original Code and all software distributed under the License are␊ |
14 | * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER␊ |
15 | * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,␊ |
16 | * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,␊ |
17 | * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.␊ |
18 | * Please see the License for the specific language governing rights and␊ |
19 | * limitations under the License.␊ |
20 | * ␊ |
21 | * @APPLE_LICENSE_HEADER_END@␊ |
22 | */␊ |
23 | /*␉$NetBSD: exec.h,v 1.6 1994/10/27 04:16:05 cgd Exp $␉*/␊ |
24 | ␊ |
25 | /*␊ |
26 | * Copyright (c) 1993 Christopher G. Demetriou␊ |
27 | * All rights reserved.␊ |
28 | *␊ |
29 | * Redistribution and use in source and binary forms, with or without␊ |
30 | * modification, are permitted provided that the following conditions␊ |
31 | * are met:␊ |
32 | * 1. Redistributions of source code must retain the above copyright␊ |
33 | * notice, this list of conditions and the following disclaimer.␊ |
34 | * 2. Redistributions in binary form must reproduce the above copyright␊ |
35 | * notice, this list of conditions and the following disclaimer in the␊ |
36 | * documentation and/or other materials provided with the distribution.␊ |
37 | * 3. The name of the author may not be used to endorse or promote products␊ |
38 | * derived from this software without specific prior written permission␊ |
39 | *␊ |
40 | * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR␊ |
41 | * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES␊ |
42 | * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.␊ |
43 | * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,␊ |
44 | * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT␊ |
45 | * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,␊ |
46 | * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY␊ |
47 | * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT␊ |
48 | * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF␊ |
49 | * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.␊ |
50 | */␊ |
51 | ␊ |
52 | #ifndef _MACHO_RELOC_H_␊ |
53 | #define _MACHO_RELOC_H_␊ |
54 | #include <stdint.h>␊ |
55 | ␊ |
56 | /*␊ |
57 | * Format of a relocation entry of a Mach-O file. Modified from the 4.3BSD␊ |
58 | * format. The modifications from the original format were changing the value␊ |
59 | * of the r_symbolnum field for "local" (r_extern == 0) relocation entries.␊ |
60 | * This modification is required to support symbols in an arbitrary number of␊ |
61 | * sections not just the three sections (text, data and bss) in a 4.3BSD file.␊ |
62 | * Also the last 4 bits have had the r_type tag added to them.␊ |
63 | */␊ |
64 | struct relocation_info {␊ |
65 | int32_t␉r_address;␉/* offset in the section to what is being␊ |
66 | ␉␉␉␉ relocated */␊ |
67 | uint32_t r_symbolnum:24,␉/* symbol index if r_extern == 1 or section␊ |
68 | ␉␉␉␉ ordinal if r_extern == 0 */␊ |
69 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
70 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
71 | ␉␉r_extern:1,␉/* does not include value of sym referenced */␊ |
72 | ␉␉r_type:4;␉/* if not 0, machine specific relocation type */␊ |
73 | };␊ |
74 | #define␉R_ABS␉0␉␉/* absolute relocation type for Mach-O files */␊ |
75 | ␊ |
76 | /*␊ |
77 | * The r_address is not really the address as it's name indicates but an offset.␊ |
78 | * In 4.3BSD a.out objects this offset is from the start of the "segment" for␊ |
79 | * which relocation entry is for (text or data). For Mach-O object files it is␊ |
80 | * also an offset but from the start of the "section" for which the relocation␊ |
81 | * entry is for. See comments in <mach-o/loader.h> about the r_address feild␊ |
82 | * in images for used with the dynamic linker.␊ |
83 | * ␊ |
84 | * In 4.3BSD a.out objects if r_extern is zero then r_symbolnum is an ordinal␊ |
85 | * for the segment the symbol being relocated is in. These ordinals are the␊ |
86 | * symbol types N_TEXT, N_DATA, N_BSS or N_ABS. In Mach-O object files these␊ |
87 | * ordinals refer to the sections in the object file in the order their section␊ |
88 | * structures appear in the headers of the object file they are in. The first␊ |
89 | * section has the ordinal 1, the second 2, and so on. This means that the␊ |
90 | * same ordinal in two different object files could refer to two different␊ |
91 | * sections. And further could have still different ordinals when combined␊ |
92 | * by the link-editor. The value R_ABS is used for relocation entries for␊ |
93 | * absolute symbols which need no further relocation.␊ |
94 | */␊ |
95 | ␊ |
96 | /*␊ |
97 | * For RISC machines some of the references are split across two instructions␊ |
98 | * and the instruction does not contain the complete value of the reference.␊ |
99 | * In these cases a second, or paired relocation entry, follows each of these␊ |
100 | * relocation entries, using a PAIR r_type, which contains the other part of the␊ |
101 | * reference not contained in the instruction. This other part is stored in the␊ |
102 | * pair's r_address field. The exact number of bits of the other part of the␊ |
103 | * reference store in the r_address field is dependent on the particular␊ |
104 | * relocation type for the particular architecture.␊ |
105 | */␊ |
106 | ␊ |
107 | /*␊ |
108 | * To make scattered loading by the link editor work correctly "local"␊ |
109 | * relocation entries can't be used when the item to be relocated is the value␊ |
110 | * of a symbol plus an offset (where the resulting expresion is outside the␊ |
111 | * block the link editor is moving, a blocks are divided at symbol addresses).␊ |
112 | * In this case. where the item is a symbol value plus offset, the link editor␊ |
113 | * needs to know more than just the section the symbol was defined. What is␊ |
114 | * needed is the actual value of the symbol without the offset so it can do the␊ |
115 | * relocation correctly based on where the value of the symbol got relocated to␊ |
116 | * not the value of the expression (with the offset added to the symbol value).␊ |
117 | * So for the NeXT 2.0 release no "local" relocation entries are ever used when␊ |
118 | * there is a non-zero offset added to a symbol. The "external" and "local"␊ |
119 | * relocation entries remain unchanged.␊ |
120 | *␊ |
121 | * The implemention is quite messy given the compatibility with the existing␊ |
122 | * relocation entry format. The ASSUMPTION is that a section will never be␊ |
123 | * bigger than 2**24 - 1 (0x00ffffff or 16,777,215) bytes. This assumption␊ |
124 | * allows the r_address (which is really an offset) to fit in 24 bits and high␊ |
125 | * bit of the r_address field in the relocation_info structure to indicate␊ |
126 | * it is really a scattered_relocation_info structure. Since these are only␊ |
127 | * used in places where "local" relocation entries are used and not where␊ |
128 | * "external" relocation entries are used the r_extern field has been removed.␊ |
129 | *␊ |
130 | * For scattered loading to work on a RISC machine where some of the references␊ |
131 | * are split across two instructions the link editor needs to be assured that␊ |
132 | * each reference has a unique 32 bit reference (that more than one reference is␊ |
133 | * NOT sharing the same high 16 bits for example) so it move each referenced␊ |
134 | * item independent of each other. Some compilers guarantees this but the␊ |
135 | * compilers don't so scattered loading can be done on those that do guarantee␊ |
136 | * this.␊ |
137 | */␊ |
138 | #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)␊ |
139 | /*␊ |
140 | * The reason for the ifdef's of __BIG_ENDIAN__ and __LITTLE_ENDIAN__ are that␊ |
141 | * when stattered relocation entries were added the mistake of using a mask␊ |
142 | * against a structure that is made up of bit fields was used. To make this␊ |
143 | * design work this structure must be laid out in memory the same way so the␊ |
144 | * mask can be applied can check the same bit each time (r_scattered).␊ |
145 | */␊ |
146 | #endif /* defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__) */␊ |
147 | #define R_SCATTERED 0x80000000␉/* mask to be applied to the r_address field ␊ |
148 | ␉␉␉␉ of a relocation_info structure to tell that␊ |
149 | ␉␉␉␉ is is really a scattered_relocation_info␊ |
150 | ␉␉␉␉ stucture */␊ |
151 | struct scattered_relocation_info {␊ |
152 | #ifdef __BIG_ENDIAN__␊ |
153 | uint32_t␉r_scattered:1,␉/* 1=scattered, 0=non-scattered (see above) */␊ |
154 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
155 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
156 | ␉␉r_type:4,␉/* if not 0, machine specific relocation type */␊ |
157 | ␉␉r_address:24;␉/* offset in the section to what is being␊ |
158 | ␉␉␉␉ relocated */␊ |
159 | int32_t␉r_value;␉/* the value the item to be relocated is␊ |
160 | ␉␉␉␉ refering to (without any offset added) */␊ |
161 | #endif /* __BIG_ENDIAN__ */␊ |
162 | #ifdef __LITTLE_ENDIAN__␊ |
163 | uint32_t␊ |
164 | ␉␉r_address:24,␉/* offset in the section to what is being␊ |
165 | ␉␉␉␉ relocated */␊ |
166 | ␉␉r_type:4,␉/* if not 0, machine specific relocation type */␊ |
167 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
168 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
169 | ␉␉r_scattered:1;␉/* 1=scattered, 0=non-scattered (see above) */␊ |
170 | int32_t␉r_value;␉/* the value the item to be relocated is␊ |
171 | ␉␉␉␉ refering to (without any offset added) */␊ |
172 | #endif /* __LITTLE_ENDIAN__ */␊ |
173 | };␊ |
174 | ␊ |
175 | /*␊ |
176 | * Relocation types used in a generic implementation. Relocation entries for␊ |
177 | * normal things use the generic relocation as discribed above and their r_type␊ |
178 | * is GENERIC_RELOC_VANILLA (a value of zero).␊ |
179 | *␊ |
180 | * Another type of generic relocation, GENERIC_RELOC_SECTDIFF, is to support␊ |
181 | * the difference of two symbols defined in different sections. That is the␊ |
182 | * expression "symbol1 - symbol2 + constant" is a relocatable expression when␊ |
183 | * both symbols are defined in some section. For this type of relocation the␊ |
184 | * both relocations entries are scattered relocation entries. The value of␊ |
185 | * symbol1 is stored in the first relocation entry's r_value field and the␊ |
186 | * value of symbol2 is stored in the pair's r_value field.␊ |
187 | *␊ |
188 | * A special case for a prebound lazy pointer is needed to beable to set the␊ |
189 | * value of the lazy pointer back to its non-prebound state. This is done␊ |
190 | * using the GENERIC_RELOC_PB_LA_PTR r_type. This is a scattered relocation␊ |
191 | * entry where the r_value feild is the value of the lazy pointer not prebound.␊ |
192 | */␊ |
193 | enum reloc_type_generic␊ |
194 | {␊ |
195 | GENERIC_RELOC_VANILLA,␉/* generic relocation as discribed above */␊ |
196 | GENERIC_RELOC_PAIR,␉␉/* Only follows a GENERIC_RELOC_SECTDIFF */␊ |
197 | GENERIC_RELOC_SECTDIFF,␊ |
198 | GENERIC_RELOC_PB_LA_PTR,␉/* prebound lazy pointer */␊ |
199 | GENERIC_RELOC_LOCAL_SECTDIFF,␊ |
200 | GENERIC_RELOC_TLV␉␉/* thread local variables */␊ |
201 | };␊ |
202 | ␊ |
203 | #endif /* _MACHO_RELOC_H_ */␊ |
204 | |