1 |
106 |
markom |
/* `a.out' object-file definitions, including extensions to 64-bit fields */
|
2 |
|
|
|
3 |
|
|
#ifndef __A_OUT_64_H__
|
4 |
|
|
#define __A_OUT_64_H__
|
5 |
|
|
|
6 |
|
|
/* This is the layout on disk of the 32-bit or 64-bit exec header. */
|
7 |
|
|
|
8 |
|
|
#ifndef external_exec
|
9 |
|
|
struct external_exec
|
10 |
|
|
{
|
11 |
|
|
bfd_byte e_info[4]; /* magic number and stuff */
|
12 |
|
|
bfd_byte e_text[BYTES_IN_WORD]; /* length of text section in bytes */
|
13 |
|
|
bfd_byte e_data[BYTES_IN_WORD]; /* length of data section in bytes */
|
14 |
|
|
bfd_byte e_bss[BYTES_IN_WORD]; /* length of bss area in bytes */
|
15 |
|
|
bfd_byte e_syms[BYTES_IN_WORD]; /* length of symbol table in bytes */
|
16 |
|
|
bfd_byte e_entry[BYTES_IN_WORD]; /* start address */
|
17 |
|
|
bfd_byte e_trsize[BYTES_IN_WORD]; /* length of text relocation info */
|
18 |
|
|
bfd_byte e_drsize[BYTES_IN_WORD]; /* length of data relocation info */
|
19 |
|
|
};
|
20 |
|
|
|
21 |
|
|
#define EXEC_BYTES_SIZE (4 + BYTES_IN_WORD * 7)
|
22 |
|
|
|
23 |
|
|
/* Magic numbers for a.out files */
|
24 |
|
|
|
25 |
|
|
#if ARCH_SIZE==64
|
26 |
|
|
#define OMAGIC 0x1001 /* Code indicating object file */
|
27 |
|
|
#define ZMAGIC 0x1002 /* Code indicating demand-paged executable. */
|
28 |
|
|
#define NMAGIC 0x1003 /* Code indicating pure executable. */
|
29 |
|
|
|
30 |
|
|
/* There is no 64-bit QMAGIC as far as I know. */
|
31 |
|
|
|
32 |
|
|
#define N_BADMAG(x) (N_MAGIC(x) != OMAGIC \
|
33 |
|
|
&& N_MAGIC(x) != NMAGIC \
|
34 |
|
|
&& N_MAGIC(x) != ZMAGIC)
|
35 |
|
|
#else
|
36 |
|
|
#define OMAGIC 0407 /* ...object file or impure executable. */
|
37 |
|
|
#define NMAGIC 0410 /* Code indicating pure executable. */
|
38 |
|
|
#define ZMAGIC 0413 /* Code indicating demand-paged executable. */
|
39 |
|
|
#define BMAGIC 0415 /* Used by a b.out object. */
|
40 |
|
|
|
41 |
|
|
/* This indicates a demand-paged executable with the header in the text.
|
42 |
|
|
It is used by 386BSD (and variants) and Linux, at least. */
|
43 |
|
|
#ifndef QMAGIC
|
44 |
|
|
#define QMAGIC 0314
|
45 |
|
|
#endif
|
46 |
|
|
# ifndef N_BADMAG
|
47 |
|
|
# define N_BADMAG(x) (N_MAGIC(x) != OMAGIC \
|
48 |
|
|
&& N_MAGIC(x) != NMAGIC \
|
49 |
|
|
&& N_MAGIC(x) != ZMAGIC \
|
50 |
|
|
&& N_MAGIC(x) != QMAGIC)
|
51 |
|
|
# endif /* N_BADMAG */
|
52 |
|
|
#endif
|
53 |
|
|
|
54 |
|
|
#endif
|
55 |
|
|
|
56 |
|
|
#ifdef QMAGIC
|
57 |
|
|
#define N_IS_QMAGIC(x) (N_MAGIC (x) == QMAGIC)
|
58 |
|
|
#else
|
59 |
|
|
#define N_IS_QMAGIC(x) (0)
|
60 |
|
|
#endif
|
61 |
|
|
|
62 |
|
|
/* The difference between TARGET_PAGE_SIZE and N_SEGSIZE is that TARGET_PAGE_SIZE is
|
63 |
|
|
the finest granularity at which you can page something, thus it
|
64 |
|
|
controls the padding (if any) before the text segment of a ZMAGIC
|
65 |
|
|
file. N_SEGSIZE is the resolution at which things can be marked as
|
66 |
|
|
read-only versus read/write, so it controls the padding between the
|
67 |
|
|
text segment and the data segment (in memory; on disk the padding
|
68 |
|
|
between them is TARGET_PAGE_SIZE). TARGET_PAGE_SIZE and N_SEGSIZE are the same
|
69 |
|
|
for most machines, but different for sun3. */
|
70 |
|
|
|
71 |
|
|
/* By default, segment size is constant. But some machines override this
|
72 |
|
|
to be a function of the a.out header (e.g. machine type). */
|
73 |
|
|
|
74 |
|
|
#ifndef N_SEGSIZE
|
75 |
|
|
#define N_SEGSIZE(x) SEGMENT_SIZE
|
76 |
|
|
#endif
|
77 |
|
|
|
78 |
|
|
/* Virtual memory address of the text section.
|
79 |
|
|
This is getting very complicated. A good reason to discard a.out format
|
80 |
|
|
for something that specifies these fields explicitly. But til then...
|
81 |
|
|
|
82 |
|
|
* OMAGIC and NMAGIC files:
|
83 |
|
|
(object files: text for "relocatable addr 0" right after the header)
|
84 |
|
|
start at 0, offset is EXEC_BYTES_SIZE, size as stated.
|
85 |
|
|
* The text address, offset, and size of ZMAGIC files depend
|
86 |
|
|
on the entry point of the file:
|
87 |
|
|
* entry point below TEXT_START_ADDR:
|
88 |
|
|
(hack for SunOS shared libraries)
|
89 |
|
|
start at 0, offset is 0, size as stated.
|
90 |
|
|
* If N_HEADER_IN_TEXT(x) is true (which defaults to being the
|
91 |
|
|
case when the entry point is EXEC_BYTES_SIZE or further into a page):
|
92 |
|
|
no padding is needed; text can start after exec header. Sun
|
93 |
|
|
considers the text segment of such files to include the exec header;
|
94 |
|
|
for BFD's purposes, we don't, which makes more work for us.
|
95 |
|
|
start at TEXT_START_ADDR + EXEC_BYTES_SIZE, offset is EXEC_BYTES_SIZE,
|
96 |
|
|
size as stated minus EXEC_BYTES_SIZE.
|
97 |
|
|
* If N_HEADER_IN_TEXT(x) is false (which defaults to being the case when
|
98 |
|
|
the entry point is less than EXEC_BYTES_SIZE into a page (e.g. page
|
99 |
|
|
aligned)): (padding is needed so that text can start at a page boundary)
|
100 |
|
|
start at TEXT_START_ADDR, offset TARGET_PAGE_SIZE, size as stated.
|
101 |
|
|
|
102 |
|
|
Specific configurations may want to hardwire N_HEADER_IN_TEXT,
|
103 |
|
|
for efficiency or to allow people to play games with the entry point.
|
104 |
|
|
In that case, you would #define N_HEADER_IN_TEXT(x) as 1 for sunos,
|
105 |
|
|
and as 0 for most other hosts (Sony News, Vax Ultrix, etc).
|
106 |
|
|
(Do this in the appropriate bfd target file.)
|
107 |
|
|
(The default is a heuristic that will break if people try changing
|
108 |
|
|
the entry point, perhaps with the ld -e flag.)
|
109 |
|
|
|
110 |
|
|
* QMAGIC is always like a ZMAGIC for which N_HEADER_IN_TEXT is true,
|
111 |
|
|
and for which the starting address is TARGET_PAGE_SIZE (or should this be
|
112 |
|
|
SEGMENT_SIZE?) (TEXT_START_ADDR only applies to ZMAGIC, not to QMAGIC).
|
113 |
|
|
*/
|
114 |
|
|
|
115 |
|
|
/* This macro is only relevant for ZMAGIC files; QMAGIC always has the header
|
116 |
|
|
in the text. */
|
117 |
|
|
#ifndef N_HEADER_IN_TEXT
|
118 |
|
|
#define N_HEADER_IN_TEXT(x) (((x).a_entry & (TARGET_PAGE_SIZE-1)) >= EXEC_BYTES_SIZE)
|
119 |
|
|
#endif
|
120 |
|
|
|
121 |
|
|
/* Sun shared libraries, not linux. This macro is only relevant for ZMAGIC
|
122 |
|
|
files. */
|
123 |
|
|
#ifndef N_SHARED_LIB
|
124 |
|
|
#if defined (TEXT_START_ADDR) && TEXT_START_ADDR == 0
|
125 |
|
|
#define N_SHARED_LIB(x) (0)
|
126 |
|
|
#else
|
127 |
|
|
#define N_SHARED_LIB(x) ((x).a_entry < TEXT_START_ADDR)
|
128 |
|
|
#endif
|
129 |
|
|
#endif
|
130 |
|
|
|
131 |
|
|
/* Returning 0 not TEXT_START_ADDR for OMAGIC and NMAGIC is based on
|
132 |
|
|
the assumption that we are dealing with a .o file, not an
|
133 |
|
|
executable. This is necessary for OMAGIC (but means we don't work
|
134 |
|
|
right on the output from ld -N); more questionable for NMAGIC. */
|
135 |
|
|
|
136 |
|
|
#ifndef N_TXTADDR
|
137 |
|
|
#define N_TXTADDR(x) \
|
138 |
|
|
(/* The address of a QMAGIC file is always one page in, */ \
|
139 |
|
|
/* with the header in the text. */ \
|
140 |
|
|
N_IS_QMAGIC (x) ? TARGET_PAGE_SIZE + EXEC_BYTES_SIZE : \
|
141 |
|
|
N_MAGIC(x) != ZMAGIC ? 0 : /* object file or NMAGIC */\
|
142 |
|
|
N_SHARED_LIB(x) ? 0 : \
|
143 |
|
|
N_HEADER_IN_TEXT(x) ? \
|
144 |
|
|
TEXT_START_ADDR + EXEC_BYTES_SIZE : /* no padding */\
|
145 |
|
|
TEXT_START_ADDR /* a page of padding */\
|
146 |
|
|
)
|
147 |
|
|
#endif
|
148 |
|
|
|
149 |
|
|
/* If N_HEADER_IN_TEXT is not true for ZMAGIC, there is some padding
|
150 |
|
|
to make the text segment start at a certain boundary. For most
|
151 |
|
|
systems, this boundary is TARGET_PAGE_SIZE. But for Linux, in the
|
152 |
|
|
time-honored tradition of crazy ZMAGIC hacks, it is 1024 which is
|
153 |
|
|
not what TARGET_PAGE_SIZE needs to be for QMAGIC. */
|
154 |
|
|
|
155 |
|
|
#ifndef ZMAGIC_DISK_BLOCK_SIZE
|
156 |
|
|
#define ZMAGIC_DISK_BLOCK_SIZE TARGET_PAGE_SIZE
|
157 |
|
|
#endif
|
158 |
|
|
|
159 |
|
|
#define N_DISK_BLOCK_SIZE(x) \
|
160 |
|
|
(N_MAGIC(x) == ZMAGIC ? ZMAGIC_DISK_BLOCK_SIZE : TARGET_PAGE_SIZE)
|
161 |
|
|
|
162 |
|
|
/* Offset in an a.out of the start of the text section. */
|
163 |
|
|
#ifndef N_TXTOFF
|
164 |
|
|
#define N_TXTOFF(x) \
|
165 |
|
|
(/* For {O,N,Q}MAGIC, no padding. */ \
|
166 |
|
|
N_MAGIC(x) != ZMAGIC ? EXEC_BYTES_SIZE : \
|
167 |
|
|
N_SHARED_LIB(x) ? 0 : \
|
168 |
|
|
N_HEADER_IN_TEXT(x) ? \
|
169 |
|
|
EXEC_BYTES_SIZE : /* no padding */\
|
170 |
|
|
ZMAGIC_DISK_BLOCK_SIZE /* a page of padding */\
|
171 |
|
|
)
|
172 |
|
|
#endif
|
173 |
|
|
/* Size of the text section. It's always as stated, except that we
|
174 |
|
|
offset it to `undo' the adjustment to N_TXTADDR and N_TXTOFF
|
175 |
|
|
for ZMAGIC files that nominally include the exec header
|
176 |
|
|
as part of the first page of text. (BFD doesn't consider the
|
177 |
|
|
exec header to be part of the text segment.) */
|
178 |
|
|
#ifndef N_TXTSIZE
|
179 |
|
|
#define N_TXTSIZE(x) \
|
180 |
|
|
(/* For QMAGIC, we don't consider the header part of the text section. */\
|
181 |
|
|
N_IS_QMAGIC (x) ? (x).a_text - EXEC_BYTES_SIZE : \
|
182 |
|
|
(N_MAGIC(x) != ZMAGIC || N_SHARED_LIB(x)) ? (x).a_text : \
|
183 |
|
|
N_HEADER_IN_TEXT(x) ? \
|
184 |
|
|
(x).a_text - EXEC_BYTES_SIZE: /* no padding */\
|
185 |
|
|
(x).a_text /* a page of padding */\
|
186 |
|
|
)
|
187 |
|
|
#endif
|
188 |
|
|
/* The address of the data segment in virtual memory.
|
189 |
|
|
It is the text segment address, plus text segment size, rounded
|
190 |
|
|
up to a N_SEGSIZE boundary for pure or pageable files. */
|
191 |
|
|
#ifndef N_DATADDR
|
192 |
|
|
#define N_DATADDR(x) \
|
193 |
|
|
(N_MAGIC(x)==OMAGIC? (N_TXTADDR(x)+N_TXTSIZE(x)) \
|
194 |
|
|
: (N_SEGSIZE(x) + ((N_TXTADDR(x)+N_TXTSIZE(x)-1) & ~(N_SEGSIZE(x)-1))))
|
195 |
|
|
#endif
|
196 |
|
|
/* The address of the BSS segment -- immediately after the data segment. */
|
197 |
|
|
|
198 |
|
|
#define N_BSSADDR(x) (N_DATADDR(x) + (x).a_data)
|
199 |
|
|
|
200 |
|
|
/* Offsets of the various portions of the file after the text segment. */
|
201 |
|
|
|
202 |
|
|
/* For {Q,Z}MAGIC, there is padding to make the data segment start on
|
203 |
|
|
a page boundary. Most of the time the a_text field (and thus
|
204 |
|
|
N_TXTSIZE) already contains this padding. It is possible that for
|
205 |
|
|
BSDI and/or 386BSD it sometimes doesn't contain the padding, and
|
206 |
|
|
perhaps we should be adding it here. But this seems kind of
|
207 |
|
|
questionable and probably should be BSDI/386BSD-specific if we do
|
208 |
|
|
do it.
|
209 |
|
|
|
210 |
|
|
For NMAGIC (at least for hp300 BSD, probably others), there is
|
211 |
|
|
padding in memory only, not on disk, so we must *not* ever pad here
|
212 |
|
|
for NMAGIC. */
|
213 |
|
|
|
214 |
|
|
#ifndef N_DATOFF
|
215 |
|
|
#define N_DATOFF(x) \
|
216 |
|
|
(N_TXTOFF(x) + N_TXTSIZE(x))
|
217 |
|
|
#endif
|
218 |
|
|
|
219 |
|
|
#ifndef N_TRELOFF
|
220 |
|
|
#define N_TRELOFF(x) ( N_DATOFF(x) + (x).a_data )
|
221 |
|
|
#endif
|
222 |
|
|
#ifndef N_DRELOFF
|
223 |
|
|
#define N_DRELOFF(x) ( N_TRELOFF(x) + (x).a_trsize )
|
224 |
|
|
#endif
|
225 |
|
|
#ifndef N_SYMOFF
|
226 |
|
|
#define N_SYMOFF(x) ( N_DRELOFF(x) + (x).a_drsize )
|
227 |
|
|
#endif
|
228 |
|
|
#ifndef N_STROFF
|
229 |
|
|
#define N_STROFF(x) ( N_SYMOFF(x) + (x).a_syms )
|
230 |
|
|
#endif
|
231 |
|
|
|
232 |
|
|
/* Symbols */
|
233 |
|
|
#ifndef external_nlist
|
234 |
|
|
struct external_nlist {
|
235 |
|
|
bfd_byte e_strx[BYTES_IN_WORD]; /* index into string table of name */
|
236 |
|
|
bfd_byte e_type[1]; /* type of symbol */
|
237 |
|
|
bfd_byte e_other[1]; /* misc info (usually empty) */
|
238 |
|
|
bfd_byte e_desc[2]; /* description field */
|
239 |
|
|
bfd_byte e_value[BYTES_IN_WORD]; /* value of symbol */
|
240 |
|
|
};
|
241 |
|
|
#define EXTERNAL_NLIST_SIZE (BYTES_IN_WORD+4+BYTES_IN_WORD)
|
242 |
|
|
#endif
|
243 |
|
|
|
244 |
|
|
struct internal_nlist {
|
245 |
|
|
unsigned long n_strx; /* index into string table of name */
|
246 |
|
|
unsigned char n_type; /* type of symbol */
|
247 |
|
|
unsigned char n_other; /* misc info (usually empty) */
|
248 |
|
|
unsigned short n_desc; /* description field */
|
249 |
|
|
bfd_vma n_value; /* value of symbol */
|
250 |
|
|
};
|
251 |
|
|
|
252 |
|
|
/* The n_type field is the symbol type, containing: */
|
253 |
|
|
|
254 |
|
|
#define N_UNDF 0 /* Undefined symbol */
|
255 |
|
|
#define N_ABS 2 /* Absolute symbol -- defined at particular addr */
|
256 |
|
|
#define N_TEXT 4 /* Text sym -- defined at offset in text seg */
|
257 |
|
|
#define N_DATA 6 /* Data sym -- defined at offset in data seg */
|
258 |
|
|
#define N_BSS 8 /* BSS sym -- defined at offset in zero'd seg */
|
259 |
|
|
#define N_COMM 0x12 /* Common symbol (visible after shared lib dynlink) */
|
260 |
|
|
#define N_FN 0x1f /* File name of .o file */
|
261 |
|
|
#define N_FN_SEQ 0x0C /* N_FN from Sequent compilers (sigh) */
|
262 |
|
|
/* Note: N_EXT can only be usefully OR-ed with N_UNDF, N_ABS, N_TEXT,
|
263 |
|
|
N_DATA, or N_BSS. When the low-order bit of other types is set,
|
264 |
|
|
(e.g. N_WARNING versus N_FN), they are two different types. */
|
265 |
|
|
#define N_EXT 1 /* External symbol (as opposed to local-to-this-file) */
|
266 |
|
|
#define N_TYPE 0x1e
|
267 |
|
|
#define N_STAB 0xe0 /* If any of these bits are on, it's a debug symbol */
|
268 |
|
|
|
269 |
|
|
#define N_INDR 0x0a
|
270 |
|
|
|
271 |
|
|
/* The following symbols refer to set elements.
|
272 |
|
|
All the N_SET[ATDB] symbols with the same name form one set.
|
273 |
|
|
Space is allocated for the set in the text section, and each set
|
274 |
|
|
elements value is stored into one word of the space.
|
275 |
|
|
The first word of the space is the length of the set (number of elements).
|
276 |
|
|
|
277 |
|
|
The address of the set is made into an N_SETV symbol
|
278 |
|
|
whose name is the same as the name of the set.
|
279 |
|
|
This symbol acts like a N_DATA global symbol
|
280 |
|
|
in that it can satisfy undefined external references. */
|
281 |
|
|
|
282 |
|
|
/* These appear as input to LD, in a .o file. */
|
283 |
|
|
#define N_SETA 0x14 /* Absolute set element symbol */
|
284 |
|
|
#define N_SETT 0x16 /* Text set element symbol */
|
285 |
|
|
#define N_SETD 0x18 /* Data set element symbol */
|
286 |
|
|
#define N_SETB 0x1A /* Bss set element symbol */
|
287 |
|
|
|
288 |
|
|
/* This is output from LD. */
|
289 |
|
|
#define N_SETV 0x1C /* Pointer to set vector in data area. */
|
290 |
|
|
|
291 |
|
|
/* Warning symbol. The text gives a warning message, the next symbol
|
292 |
|
|
in the table will be undefined. When the symbol is referenced, the
|
293 |
|
|
message is printed. */
|
294 |
|
|
|
295 |
|
|
#define N_WARNING 0x1e
|
296 |
|
|
|
297 |
|
|
/* Weak symbols. These are a GNU extension to the a.out format. The
|
298 |
|
|
semantics are those of ELF weak symbols. Weak symbols are always
|
299 |
|
|
externally visible. The N_WEAK? values are squeezed into the
|
300 |
|
|
available slots. The value of a N_WEAKU symbol is 0. The values
|
301 |
|
|
of the other types are the definitions. */
|
302 |
|
|
#define N_WEAKU 0x0d /* Weak undefined symbol. */
|
303 |
|
|
#define N_WEAKA 0x0e /* Weak absolute symbol. */
|
304 |
|
|
#define N_WEAKT 0x0f /* Weak text symbol. */
|
305 |
|
|
#define N_WEAKD 0x10 /* Weak data symbol. */
|
306 |
|
|
#define N_WEAKB 0x11 /* Weak bss symbol. */
|
307 |
|
|
|
308 |
|
|
/* Relocations
|
309 |
|
|
|
310 |
|
|
There are two types of relocation flavours for a.out systems,
|
311 |
|
|
standard and extended. The standard form is used on systems where the
|
312 |
|
|
instruction has room for all the bits of an offset to the operand, whilst
|
313 |
|
|
the extended form is used when an address operand has to be split over n
|
314 |
|
|
instructions. Eg, on the 68k, each move instruction can reference
|
315 |
|
|
the target with a displacement of 16 or 32 bits. On the sparc, move
|
316 |
|
|
instructions use an offset of 14 bits, so the offset is stored in
|
317 |
|
|
the reloc field, and the data in the section is ignored.
|
318 |
|
|
*/
|
319 |
|
|
|
320 |
|
|
/* This structure describes a single relocation to be performed.
|
321 |
|
|
The text-relocation section of the file is a vector of these structures,
|
322 |
|
|
all of which apply to the text section.
|
323 |
|
|
Likewise, the data-relocation section applies to the data section. */
|
324 |
|
|
|
325 |
|
|
struct reloc_std_external {
|
326 |
|
|
bfd_byte r_address[BYTES_IN_WORD]; /* offset of of data to relocate */
|
327 |
|
|
bfd_byte r_index[3]; /* symbol table index of symbol */
|
328 |
|
|
bfd_byte r_type[1]; /* relocation type */
|
329 |
|
|
};
|
330 |
|
|
|
331 |
|
|
#define RELOC_STD_BITS_PCREL_BIG ((unsigned int) 0x80)
|
332 |
|
|
#define RELOC_STD_BITS_PCREL_LITTLE ((unsigned int) 0x01)
|
333 |
|
|
|
334 |
|
|
#define RELOC_STD_BITS_LENGTH_BIG ((unsigned int) 0x60)
|
335 |
|
|
#define RELOC_STD_BITS_LENGTH_SH_BIG 5
|
336 |
|
|
#define RELOC_STD_BITS_LENGTH_LITTLE ((unsigned int) 0x06)
|
337 |
|
|
#define RELOC_STD_BITS_LENGTH_SH_LITTLE 1
|
338 |
|
|
|
339 |
|
|
#define RELOC_STD_BITS_EXTERN_BIG ((unsigned int) 0x10)
|
340 |
|
|
#define RELOC_STD_BITS_EXTERN_LITTLE ((unsigned int) 0x08)
|
341 |
|
|
|
342 |
|
|
#define RELOC_STD_BITS_BASEREL_BIG ((unsigned int) 0x08)
|
343 |
|
|
#define RELOC_STD_BITS_BASEREL_LITTLE ((unsigned int) 0x10)
|
344 |
|
|
|
345 |
|
|
#define RELOC_STD_BITS_JMPTABLE_BIG ((unsigned int) 0x04)
|
346 |
|
|
#define RELOC_STD_BITS_JMPTABLE_LITTLE ((unsigned int) 0x20)
|
347 |
|
|
|
348 |
|
|
#define RELOC_STD_BITS_RELATIVE_BIG ((unsigned int) 0x02)
|
349 |
|
|
#define RELOC_STD_BITS_RELATIVE_LITTLE ((unsigned int) 0x40)
|
350 |
|
|
|
351 |
|
|
#define RELOC_STD_SIZE (BYTES_IN_WORD + 3 + 1) /* Bytes per relocation entry */
|
352 |
|
|
|
353 |
|
|
struct reloc_std_internal
|
354 |
|
|
{
|
355 |
|
|
bfd_vma r_address; /* Address (within segment) to be relocated. */
|
356 |
|
|
/* The meaning of r_symbolnum depends on r_extern. */
|
357 |
|
|
unsigned int r_symbolnum:24;
|
358 |
|
|
/* Nonzero means value is a pc-relative offset
|
359 |
|
|
and it should be relocated for changes in its own address
|
360 |
|
|
as well as for changes in the symbol or section specified. */
|
361 |
|
|
unsigned int r_pcrel:1;
|
362 |
|
|
/* Length (as exponent of 2) of the field to be relocated.
|
363 |
|
|
Thus, a value of 2 indicates 1<<2 bytes. */
|
364 |
|
|
unsigned int r_length:2;
|
365 |
|
|
/* 1 => relocate with value of symbol.
|
366 |
|
|
r_symbolnum is the index of the symbol
|
367 |
|
|
in files the symbol table.
|
368 |
|
|
|
369 |
|
|
r_symbolnum is N_TEXT, N_DATA, N_BSS or N_ABS
|
370 |
|
|
(the N_EXT bit may be set also, but signifies nothing). */
|
371 |
|
|
unsigned int r_extern:1;
|
372 |
|
|
/* The next three bits are for SunOS shared libraries, and seem to
|
373 |
|
|
be undocumented. */
|
374 |
|
|
unsigned int r_baserel:1; /* Linkage table relative */
|
375 |
|
|
unsigned int r_jmptable:1; /* pc-relative to jump table */
|
376 |
|
|
unsigned int r_relative:1; /* "relative relocation" */
|
377 |
|
|
/* unused */
|
378 |
|
|
unsigned int r_pad:1; /* Padding -- set to zero */
|
379 |
|
|
};
|
380 |
|
|
|
381 |
|
|
|
382 |
|
|
/* EXTENDED RELOCS */
|
383 |
|
|
|
384 |
|
|
struct reloc_ext_external {
|
385 |
|
|
bfd_byte r_address[BYTES_IN_WORD]; /* offset of of data to relocate */
|
386 |
|
|
bfd_byte r_index[3]; /* symbol table index of symbol */
|
387 |
|
|
bfd_byte r_type[1]; /* relocation type */
|
388 |
|
|
bfd_byte r_addend[BYTES_IN_WORD]; /* datum addend */
|
389 |
|
|
};
|
390 |
|
|
|
391 |
|
|
#ifndef RELOC_EXT_BITS_EXTERN_BIG
|
392 |
|
|
#define RELOC_EXT_BITS_EXTERN_BIG ((unsigned int) 0x80)
|
393 |
|
|
#endif
|
394 |
|
|
|
395 |
|
|
#ifndef RELOC_EXT_BITS_EXTERN_LITTLE
|
396 |
|
|
#define RELOC_EXT_BITS_EXTERN_LITTLE ((unsigned int) 0x01)
|
397 |
|
|
#endif
|
398 |
|
|
|
399 |
|
|
#ifndef RELOC_EXT_BITS_TYPE_BIG
|
400 |
|
|
#define RELOC_EXT_BITS_TYPE_BIG ((unsigned int) 0x1F)
|
401 |
|
|
#endif
|
402 |
|
|
|
403 |
|
|
#ifndef RELOC_EXT_BITS_TYPE_SH_BIG
|
404 |
|
|
#define RELOC_EXT_BITS_TYPE_SH_BIG 0
|
405 |
|
|
#endif
|
406 |
|
|
|
407 |
|
|
#ifndef RELOC_EXT_BITS_TYPE_LITTLE
|
408 |
|
|
#define RELOC_EXT_BITS_TYPE_LITTLE ((unsigned int) 0xF8)
|
409 |
|
|
#endif
|
410 |
|
|
|
411 |
|
|
#ifndef RELOC_EXT_BITS_TYPE_SH_LITTLE
|
412 |
|
|
#define RELOC_EXT_BITS_TYPE_SH_LITTLE 3
|
413 |
|
|
#endif
|
414 |
|
|
|
415 |
|
|
/* Bytes per relocation entry */
|
416 |
|
|
#define RELOC_EXT_SIZE (BYTES_IN_WORD + 3 + 1 + BYTES_IN_WORD)
|
417 |
|
|
|
418 |
|
|
enum reloc_type
|
419 |
|
|
{
|
420 |
|
|
/* simple relocations */
|
421 |
|
|
RELOC_8, /* data[0:7] = addend + sv */
|
422 |
|
|
RELOC_16, /* data[0:15] = addend + sv */
|
423 |
|
|
RELOC_32, /* data[0:31] = addend + sv */
|
424 |
|
|
/* pc-rel displacement */
|
425 |
|
|
RELOC_DISP8, /* data[0:7] = addend - pc + sv */
|
426 |
|
|
RELOC_DISP16, /* data[0:15] = addend - pc + sv */
|
427 |
|
|
RELOC_DISP32, /* data[0:31] = addend - pc + sv */
|
428 |
|
|
/* Special */
|
429 |
|
|
RELOC_WDISP30, /* data[0:29] = (addend + sv - pc)>>2 */
|
430 |
|
|
RELOC_WDISP22, /* data[0:21] = (addend + sv - pc)>>2 */
|
431 |
|
|
RELOC_HI22, /* data[0:21] = (addend + sv)>>10 */
|
432 |
|
|
RELOC_22, /* data[0:21] = (addend + sv) */
|
433 |
|
|
RELOC_13, /* data[0:12] = (addend + sv) */
|
434 |
|
|
RELOC_LO10, /* data[0:9] = (addend + sv) */
|
435 |
|
|
RELOC_SFA_BASE,
|
436 |
|
|
RELOC_SFA_OFF13,
|
437 |
|
|
/* P.I.C. (base-relative) */
|
438 |
|
|
RELOC_BASE10, /* Not sure - maybe we can do this the */
|
439 |
|
|
RELOC_BASE13, /* right way now */
|
440 |
|
|
RELOC_BASE22,
|
441 |
|
|
/* for some sort of pc-rel P.I.C. (?) */
|
442 |
|
|
RELOC_PC10,
|
443 |
|
|
RELOC_PC22,
|
444 |
|
|
/* P.I.C. jump table */
|
445 |
|
|
RELOC_JMP_TBL,
|
446 |
|
|
/* reputedly for shared libraries somehow */
|
447 |
|
|
RELOC_SEGOFF16,
|
448 |
|
|
RELOC_GLOB_DAT,
|
449 |
|
|
RELOC_JMP_SLOT,
|
450 |
|
|
RELOC_RELATIVE,
|
451 |
|
|
|
452 |
|
|
RELOC_11,
|
453 |
|
|
RELOC_WDISP2_14,
|
454 |
|
|
RELOC_WDISP19,
|
455 |
|
|
RELOC_HHI22, /* data[0:21] = (addend + sv) >> 42 */
|
456 |
|
|
RELOC_HLO10, /* data[0:9] = (addend + sv) >> 32 */
|
457 |
|
|
|
458 |
|
|
/* 29K relocation types */
|
459 |
|
|
RELOC_JUMPTARG,
|
460 |
|
|
RELOC_CONST,
|
461 |
|
|
RELOC_CONSTH,
|
462 |
|
|
|
463 |
|
|
/* All the new ones I can think of, for sparc v9 */
|
464 |
|
|
|
465 |
|
|
RELOC_64, /* data[0:63] = addend + sv */
|
466 |
|
|
RELOC_DISP64, /* data[0:63] = addend - pc + sv */
|
467 |
|
|
RELOC_WDISP21, /* data[0:20] = (addend + sv - pc)>>2 */
|
468 |
|
|
RELOC_DISP21, /* data[0:20] = addend - pc + sv */
|
469 |
|
|
RELOC_DISP14, /* data[0:13] = addend - pc + sv */
|
470 |
|
|
/* Q .
|
471 |
|
|
What are the other ones,
|
472 |
|
|
Since this is a clean slate, can we throw away the ones we dont
|
473 |
|
|
understand ? Should we sort the values ? What about using a
|
474 |
|
|
microcode format like the 68k ?
|
475 |
|
|
*/
|
476 |
|
|
NO_RELOC
|
477 |
|
|
};
|
478 |
|
|
|
479 |
|
|
|
480 |
|
|
struct reloc_internal {
|
481 |
|
|
bfd_vma r_address; /* offset of of data to relocate */
|
482 |
|
|
long r_index; /* symbol table index of symbol */
|
483 |
|
|
enum reloc_type r_type; /* relocation type */
|
484 |
|
|
bfd_vma r_addend; /* datum addend */
|
485 |
|
|
};
|
486 |
|
|
|
487 |
|
|
/* Q.
|
488 |
|
|
Should the length of the string table be 4 bytes or 8 bytes ?
|
489 |
|
|
|
490 |
|
|
Q.
|
491 |
|
|
What about archive indexes ?
|
492 |
|
|
|
493 |
|
|
*/
|
494 |
|
|
|
495 |
|
|
#endif /* __A_OUT_64_H__ */
|