]>
Commit | Line | Data |
---|---|---|
c618de01 | 1 | /* BFD support for handling relocation entries. |
1d5c6cfd DE |
2 | Copyright (C) 1990, 91, 92, 93, 94, 95, 1996, 1997 |
3 | Free Software Foundation, Inc. | |
c618de01 SC |
4 | Written by Cygnus Support. |
5 | ||
6 | This file is part of BFD, the Binary File Descriptor library. | |
7 | ||
8 | This program is free software; you can redistribute it and/or modify | |
9 | it under the terms of the GNU General Public License as published by | |
10 | the Free Software Foundation; either version 2 of the License, or | |
11 | (at your option) any later version. | |
12 | ||
13 | This program is distributed in the hope that it will be useful, | |
14 | but WITHOUT ANY WARRANTY; without even the implied warranty of | |
15 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
16 | GNU General Public License for more details. | |
17 | ||
18 | You should have received a copy of the GNU General Public License | |
19 | along with this program; if not, write to the Free Software | |
e9f03cd4 | 20 | Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ |
c618de01 | 21 | |
0cda46cf SC |
22 | /* |
23 | SECTION | |
24 | Relocations | |
985fca12 | 25 | |
c188b0be DM |
26 | BFD maintains relocations in much the same way it maintains |
27 | symbols: they are left alone until required, then read in | |
28 | en-mass and translated into an internal form. A common | |
29 | routine <<bfd_perform_relocation>> acts upon the | |
30 | canonical form to do the fixup. | |
985fca12 | 31 | |
c188b0be DM |
32 | Relocations are maintained on a per section basis, |
33 | while symbols are maintained on a per BFD basis. | |
985fca12 | 34 | |
c188b0be DM |
35 | All that a back end has to do to fit the BFD interface is to create |
36 | a <<struct reloc_cache_entry>> for each relocation | |
37 | in a particular section, and fill in the right bits of the structures. | |
985fca12 SC |
38 | |
39 | @menu | |
e98e6ec1 SC |
40 | @* typedef arelent:: |
41 | @* howto manager:: | |
985fca12 SC |
42 | @end menu |
43 | ||
44 | */ | |
0443af31 KR |
45 | |
46 | /* DO compile in the reloc_code name table from libbfd.h. */ | |
47 | #define _BFD_MAKE_TABLE_bfd_reloc_code_real | |
48 | ||
985fca12 | 49 | #include "bfd.h" |
0cda46cf | 50 | #include "sysdep.h" |
4c3721d5 | 51 | #include "bfdlink.h" |
985fca12 | 52 | #include "libbfd.h" |
c26d7d17 SC |
53 | /* |
54 | DOCDD | |
e98e6ec1 SC |
55 | INODE |
56 | typedef arelent, howto manager, Relocations, Relocations | |
985fca12 | 57 | |
0cda46cf SC |
58 | SUBSECTION |
59 | typedef arelent | |
985fca12 | 60 | |
e98e6ec1 | 61 | This is the structure of a relocation entry: |
985fca12 | 62 | |
e98e6ec1 SC |
63 | CODE_FRAGMENT |
64 | . | |
326e32d7 | 65 | .typedef enum bfd_reloc_status |
e98e6ec1 SC |
66 | .{ |
67 | . {* No errors detected *} | |
0cda46cf | 68 | . bfd_reloc_ok, |
e98e6ec1 SC |
69 | . |
70 | . {* The relocation was performed, but there was an overflow. *} | |
0cda46cf | 71 | . bfd_reloc_overflow, |
e98e6ec1 | 72 | . |
65cab589 | 73 | . {* The address to relocate was not within the section supplied. *} |
0cda46cf | 74 | . bfd_reloc_outofrange, |
e98e6ec1 SC |
75 | . |
76 | . {* Used by special functions *} | |
0cda46cf | 77 | . bfd_reloc_continue, |
e98e6ec1 | 78 | . |
c188b0be | 79 | . {* Unsupported relocation size requested. *} |
0cda46cf | 80 | . bfd_reloc_notsupported, |
e98e6ec1 | 81 | . |
c188b0be | 82 | . {* Unused *} |
0cda46cf | 83 | . bfd_reloc_other, |
e98e6ec1 | 84 | . |
65cab589 | 85 | . {* The symbol to relocate against was undefined. *} |
0cda46cf | 86 | . bfd_reloc_undefined, |
e98e6ec1 SC |
87 | . |
88 | . {* The relocation was performed, but may not be ok - presently | |
89 | . generated only when linking i960 coff files with i960 b.out | |
4c3721d5 ILT |
90 | . symbols. If this type is returned, the error_message argument |
91 | . to bfd_perform_relocation will be set. *} | |
0cda46cf | 92 | . bfd_reloc_dangerous |
e98e6ec1 | 93 | . } |
0cda46cf | 94 | . bfd_reloc_status_type; |
e98e6ec1 SC |
95 | . |
96 | . | |
326e32d7 | 97 | .typedef struct reloc_cache_entry |
0cda46cf | 98 | .{ |
e98e6ec1 SC |
99 | . {* A pointer into the canonical table of pointers *} |
100 | . struct symbol_cache_entry **sym_ptr_ptr; | |
101 | . | |
102 | . {* offset in section *} | |
65cab589 | 103 | . bfd_size_type address; |
e98e6ec1 SC |
104 | . |
105 | . {* addend for relocation value *} | |
326e32d7 | 106 | . bfd_vma addend; |
e98e6ec1 SC |
107 | . |
108 | . {* Pointer to how to perform the required relocation *} | |
e9f03cd4 | 109 | . reloc_howto_type *howto; |
e98e6ec1 SC |
110 | . |
111 | .} arelent; | |
985fca12 | 112 | |
e98e6ec1 | 113 | */ |
985fca12 | 114 | |
e98e6ec1 SC |
115 | /* |
116 | DESCRIPTION | |
985fca12 | 117 | |
c188b0be | 118 | Here is a description of each of the fields within an <<arelent>>: |
985fca12 | 119 | |
c188b0be | 120 | o <<sym_ptr_ptr>> |
985fca12 | 121 | |
e98e6ec1 | 122 | The symbol table pointer points to a pointer to the symbol |
c188b0be DM |
123 | associated with the relocation request. It is |
124 | the pointer into the table returned by the back end's | |
125 | <<get_symtab>> action. @xref{Symbols}. The symbol is referenced | |
e98e6ec1 SC |
126 | through a pointer to a pointer so that tools like the linker |
127 | can fix up all the symbols of the same name by modifying only | |
128 | one pointer. The relocation routine looks in the symbol and | |
129 | uses the base of the section the symbol is attached to and the | |
130 | value of the symbol as the initial relocation offset. If the | |
131 | symbol pointer is zero, then the section provided is looked up. | |
985fca12 | 132 | |
c188b0be | 133 | o <<address>> |
985fca12 | 134 | |
c188b0be | 135 | The <<address>> field gives the offset in bytes from the base of |
e98e6ec1 SC |
136 | the section data which owns the relocation record to the first |
137 | byte of relocatable information. The actual data relocated | |
c188b0be | 138 | will be relative to this point; for example, a relocation |
e98e6ec1 SC |
139 | type which modifies the bottom two bytes of a four byte word |
140 | would not touch the first byte pointed to in a big endian | |
c26d7d17 | 141 | world. |
6b31fd3a | 142 | |
c188b0be | 143 | o <<addend>> |
c26d7d17 | 144 | |
c188b0be | 145 | The <<addend>> is a value provided by the back end to be added (!) |
c26d7d17 SC |
146 | to the relocation offset. Its interpretation is dependent upon |
147 | the howto. For example, on the 68k the code: | |
985fca12 | 148 | |
985fca12 | 149 | |
e98e6ec1 SC |
150 | | char foo[]; |
151 | | main() | |
152 | | { | |
153 | | return foo[0x12345678]; | |
154 | | } | |
985fca12 | 155 | |
e98e6ec1 | 156 | Could be compiled into: |
985fca12 | 157 | |
e98e6ec1 SC |
158 | | linkw fp,#-4 |
159 | | moveb @@#12345678,d0 | |
160 | | extbl d0 | |
161 | | unlk fp | |
162 | | rts | |
985fca12 | 163 | |
985fca12 | 164 | |
c188b0be DM |
165 | This could create a reloc pointing to <<foo>>, but leave the |
166 | offset in the data, something like: | |
0cda46cf | 167 | |
985fca12 | 168 | |
e98e6ec1 | 169 | |RELOCATION RECORDS FOR [.text]: |
326e32d7 | 170 | |offset type value |
e98e6ec1 SC |
171 | |00000006 32 _foo |
172 | | | |
173 | |00000000 4e56 fffc ; linkw fp,#-4 | |
174 | |00000004 1039 1234 5678 ; moveb @@#12345678,d0 | |
175 | |0000000a 49c0 ; extbl d0 | |
176 | |0000000c 4e5e ; unlk fp | |
177 | |0000000e 4e75 ; rts | |
0cda46cf | 178 | |
985fca12 | 179 | |
e98e6ec1 SC |
180 | Using coff and an 88k, some instructions don't have enough |
181 | space in them to represent the full address range, and | |
182 | pointers have to be loaded in two parts. So you'd get something like: | |
0cda46cf | 183 | |
985fca12 | 184 | |
e98e6ec1 SC |
185 | | or.u r13,r0,hi16(_foo+0x12345678) |
186 | | ld.b r2,r13,lo16(_foo+0x12345678) | |
187 | | jmp r1 | |
985fca12 | 188 | |
985fca12 | 189 | |
c188b0be | 190 | This should create two relocs, both pointing to <<_foo>>, and with |
e98e6ec1 | 191 | 0x12340000 in their addend field. The data would consist of: |
0cda46cf | 192 | |
985fca12 | 193 | |
e98e6ec1 | 194 | |RELOCATION RECORDS FOR [.text]: |
326e32d7 | 195 | |offset type value |
e98e6ec1 SC |
196 | |00000002 HVRT16 _foo+0x12340000 |
197 | |00000006 LVRT16 _foo+0x12340000 | |
4c3721d5 | 198 | | |
e98e6ec1 SC |
199 | |00000000 5da05678 ; or.u r13,r0,0x5678 |
200 | |00000004 1c4d5678 ; ld.b r2,r13,0x5678 | |
201 | |00000008 f400c001 ; jmp r1 | |
985fca12 | 202 | |
0cda46cf | 203 | |
e98e6ec1 | 204 | The relocation routine digs out the value from the data, adds |
c188b0be DM |
205 | it to the addend to get the original offset, and then adds the |
206 | value of <<_foo>>. Note that all 32 bits have to be kept around | |
e98e6ec1 | 207 | somewhere, to cope with carry from bit 15 to bit 16. |
985fca12 | 208 | |
65cab589 | 209 | One further example is the sparc and the a.out format. The |
e98e6ec1 SC |
210 | sparc has a similar problem to the 88k, in that some |
211 | instructions don't have room for an entire offset, but on the | |
c188b0be DM |
212 | sparc the parts are created in odd sized lumps. The designers of |
213 | the a.out format chose to not use the data within the section | |
e98e6ec1 | 214 | for storing part of the offset; all the offset is kept within |
326e32d7 | 215 | the reloc. Anything in the data should be ignored. |
0cda46cf | 216 | |
e98e6ec1 SC |
217 | | save %sp,-112,%sp |
218 | | sethi %hi(_foo+0x12345678),%g2 | |
219 | | ldsb [%g2+%lo(_foo+0x12345678)],%i0 | |
220 | | ret | |
221 | | restore | |
0cda46cf | 222 | |
4c3721d5 | 223 | Both relocs contain a pointer to <<foo>>, and the offsets |
e98e6ec1 | 224 | contain junk. |
985fca12 | 225 | |
0cda46cf | 226 | |
e98e6ec1 | 227 | |RELOCATION RECORDS FOR [.text]: |
326e32d7 | 228 | |offset type value |
e98e6ec1 SC |
229 | |00000004 HI22 _foo+0x12345678 |
230 | |00000008 LO10 _foo+0x12345678 | |
4c3721d5 | 231 | | |
e98e6ec1 SC |
232 | |00000000 9de3bf90 ; save %sp,-112,%sp |
233 | |00000004 05000000 ; sethi %hi(_foo+0),%g2 | |
234 | |00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0 | |
235 | |0000000c 81c7e008 ; ret | |
236 | |00000010 81e80000 ; restore | |
237 | ||
0cda46cf | 238 | |
c188b0be | 239 | o <<howto>> |
e98e6ec1 | 240 | |
c188b0be DM |
241 | The <<howto>> field can be imagined as a |
242 | relocation instruction. It is a pointer to a structure which | |
243 | contains information on what to do with all of the other | |
e98e6ec1 SC |
244 | information in the reloc record and data section. A back end |
245 | would normally have a relocation instruction set and turn | |
246 | relocations into pointers to the correct structure on input - | |
247 | but it would be possible to create each howto field on demand. | |
326e32d7 | 248 | |
985fca12 SC |
249 | */ |
250 | ||
66a277ab ILT |
251 | /* |
252 | SUBSUBSECTION | |
253 | <<enum complain_overflow>> | |
254 | ||
255 | Indicates what sort of overflow checking should be done when | |
256 | performing a relocation. | |
257 | ||
258 | CODE_FRAGMENT | |
259 | . | |
260 | .enum complain_overflow | |
261 | .{ | |
262 | . {* Do not complain on overflow. *} | |
263 | . complain_overflow_dont, | |
264 | . | |
265 | . {* Complain if the bitfield overflows, whether it is considered | |
266 | . as signed or unsigned. *} | |
267 | . complain_overflow_bitfield, | |
268 | . | |
269 | . {* Complain if the value overflows when considered as signed | |
270 | . number. *} | |
271 | . complain_overflow_signed, | |
272 | . | |
273 | . {* Complain if the value overflows when considered as an | |
274 | . unsigned number. *} | |
275 | . complain_overflow_unsigned | |
276 | .}; | |
277 | ||
278 | */ | |
985fca12 | 279 | |
0cda46cf | 280 | /* |
326e32d7 | 281 | SUBSUBSECTION |
e98e6ec1 | 282 | <<reloc_howto_type>> |
985fca12 | 283 | |
e98e6ec1 | 284 | The <<reloc_howto_type>> is a structure which contains all the |
c188b0be | 285 | information that libbfd needs to know to tie up a back end's data. |
985fca12 | 286 | |
e98e6ec1 | 287 | CODE_FRAGMENT |
5022aea5 | 288 | .struct symbol_cache_entry; {* Forward declaration *} |
e98e6ec1 | 289 | . |
1fb83be6 | 290 | .struct reloc_howto_struct |
326e32d7 | 291 | .{ |
e98e6ec1 | 292 | . {* The type field has mainly a documetary use - the back end can |
c188b0be DM |
293 | . do what it wants with it, though normally the back end's |
294 | . external idea of what a reloc number is stored | |
295 | . in this field. For example, a PC relative word relocation | |
296 | . in a coff environment has the type 023 - because that's | |
e98e6ec1 | 297 | . what the outside world calls a R_PCRWORD reloc. *} |
0cda46cf | 298 | . unsigned int type; |
e98e6ec1 SC |
299 | . |
300 | . {* The value the final relocation is shifted right by. This drops | |
301 | . unwanted data from the relocation. *} | |
0cda46cf | 302 | . unsigned int rightshift; |
e98e6ec1 | 303 | . |
fb32909a | 304 | . {* The size of the item to be relocated. This is *not* a |
4c3721d5 ILT |
305 | . power-of-two measure. To get the number of bytes operated |
306 | . on by a type of relocation, use bfd_get_reloc_size. *} | |
c26d7d17 | 307 | . int size; |
e98e6ec1 | 308 | . |
66a277ab ILT |
309 | . {* The number of bits in the item to be relocated. This is used |
310 | . when doing overflow checking. *} | |
0cda46cf | 311 | . unsigned int bitsize; |
e98e6ec1 SC |
312 | . |
313 | . {* Notes that the relocation is relative to the location in the | |
314 | . data section of the addend. The relocation function will | |
315 | . subtract from the relocation value the address of the location | |
316 | . being relocated. *} | |
0cda46cf | 317 | . boolean pc_relative; |
e98e6ec1 | 318 | . |
66a277ab ILT |
319 | . {* The bit position of the reloc value in the destination. |
320 | . The relocated value is left shifted by this amount. *} | |
0cda46cf | 321 | . unsigned int bitpos; |
e98e6ec1 | 322 | . |
66a277ab ILT |
323 | . {* What type of overflow error should be checked for when |
324 | . relocating. *} | |
325 | . enum complain_overflow complain_on_overflow; | |
e98e6ec1 SC |
326 | . |
327 | . {* If this field is non null, then the supplied function is | |
328 | . called rather than the normal function. This allows really | |
65cab589 | 329 | . strange relocation methods to be accomodated (e.g., i960 callj |
e98e6ec1 | 330 | . instructions). *} |
326e32d7 | 331 | . bfd_reloc_status_type (*special_function) |
fefb4b30 | 332 | . PARAMS ((bfd *abfd, |
5022aea5 SC |
333 | . arelent *reloc_entry, |
334 | . struct symbol_cache_entry *symbol, | |
335 | . PTR data, | |
326e32d7 | 336 | . asection *input_section, |
4c3721d5 ILT |
337 | . bfd *output_bfd, |
338 | . char **error_message)); | |
e98e6ec1 SC |
339 | . |
340 | . {* The textual name of the relocation type. *} | |
0cda46cf | 341 | . char *name; |
e98e6ec1 SC |
342 | . |
343 | . {* When performing a partial link, some formats must modify the | |
344 | . relocations rather than the data - this flag signals this.*} | |
0cda46cf | 345 | . boolean partial_inplace; |
e98e6ec1 | 346 | . |
c188b0be | 347 | . {* The src_mask selects which parts of the read in data |
65cab589 | 348 | . are to be used in the relocation sum. E.g., if this was an 8 bit |
e98e6ec1 SC |
349 | . bit of data which we read and relocated, this would be |
350 | . 0x000000ff. When we have relocs which have an addend, such as | |
351 | . sun4 extended relocs, the value in the offset part of a | |
352 | . relocating field is garbage so we never use it. In this case | |
353 | . the mask would be 0x00000000. *} | |
65cab589 | 354 | . bfd_vma src_mask; |
e98e6ec1 | 355 | . |
c188b0be | 356 | . {* The dst_mask selects which parts of the instruction are replaced |
e98e6ec1 SC |
357 | . into the instruction. In most cases src_mask == dst_mask, |
358 | . except in the above special case, where dst_mask would be | |
359 | . 0x000000ff, and src_mask would be 0x00000000. *} | |
326e32d7 | 360 | . bfd_vma dst_mask; |
e98e6ec1 SC |
361 | . |
362 | . {* When some formats create PC relative instructions, they leave | |
363 | . the value of the pc of the place being relocated in the offset | |
364 | . slot of the instruction, so that a PC relative relocation can | |
65cab589 | 365 | . be made just by adding in an ordinary offset (e.g., sun3 a.out). |
e98e6ec1 | 366 | . Some formats leave the displacement part of an instruction |
c188b0be | 367 | . empty (e.g., m88k bcs); this flag signals the fact.*} |
0cda46cf | 368 | . boolean pcrel_offset; |
e98e6ec1 | 369 | . |
1fb83be6 | 370 | .}; |
985fca12 | 371 | |
0cda46cf | 372 | */ |
985fca12 | 373 | |
0cda46cf SC |
374 | /* |
375 | FUNCTION | |
c188b0be | 376 | The HOWTO Macro |
e98e6ec1 | 377 | |
0cda46cf SC |
378 | DESCRIPTION |
379 | The HOWTO define is horrible and will go away. | |
380 | ||
381 | ||
66a277ab | 382 | .#define HOWTO(C, R,S,B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \ |
0443af31 | 383 | . {(unsigned)C,R,S,B, P, BI, O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC} |
0cda46cf SC |
384 | |
385 | DESCRIPTION | |
386 | And will be replaced with the totally magic way. But for the | |
c188b0be | 387 | moment, we are compatible, so do it this way. |
0cda46cf SC |
388 | |
389 | ||
66a277ab | 390 | .#define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,complain_overflow_dont,FUNCTION, NAME,false,0,0,IN) |
0cda46cf SC |
391 | . |
392 | DESCRIPTION | |
393 | Helper routine to turn a symbol into a relocation value. | |
394 | ||
e98e6ec1 SC |
395 | .#define HOWTO_PREPARE(relocation, symbol) \ |
396 | . { \ | |
397 | . if (symbol != (asymbol *)NULL) { \ | |
65cab589 | 398 | . if (bfd_is_com_section (symbol->section)) { \ |
e98e6ec1 SC |
399 | . relocation = 0; \ |
400 | . } \ | |
401 | . else { \ | |
402 | . relocation = symbol->value; \ | |
403 | . } \ | |
404 | . } \ | |
326e32d7 | 405 | .} |
985fca12 SC |
406 | |
407 | */ | |
408 | ||
4c3721d5 ILT |
409 | /* |
410 | FUNCTION | |
411 | bfd_get_reloc_size | |
412 | ||
413 | SYNOPSIS | |
82b1edf7 | 414 | int bfd_get_reloc_size (reloc_howto_type *); |
4c3721d5 ILT |
415 | |
416 | DESCRIPTION | |
417 | For a reloc_howto_type that operates on a fixed number of bytes, | |
418 | this returns the number of bytes operated on. | |
419 | */ | |
420 | ||
421 | int | |
422 | bfd_get_reloc_size (howto) | |
82b1edf7 | 423 | reloc_howto_type *howto; |
4c3721d5 | 424 | { |
326e32d7 ILT |
425 | switch (howto->size) |
426 | { | |
427 | case 0: return 1; | |
428 | case 1: return 2; | |
429 | case 2: return 4; | |
430 | case 3: return 0; | |
431 | case 4: return 8; | |
8612a388 | 432 | case 8: return 16; |
326e32d7 ILT |
433 | case -2: return 4; |
434 | default: abort (); | |
435 | } | |
4c3721d5 ILT |
436 | } |
437 | ||
0cda46cf SC |
438 | /* |
439 | TYPEDEF | |
c188b0be | 440 | arelent_chain |
985fca12 | 441 | |
0cda46cf | 442 | DESCRIPTION |
985fca12 | 443 | |
c188b0be | 444 | How relocs are tied together in an <<asection>>: |
985fca12 | 445 | |
0cda46cf SC |
446 | .typedef struct relent_chain { |
447 | . arelent relent; | |
448 | . struct relent_chain *next; | |
449 | .} arelent_chain; | |
985fca12 SC |
450 | |
451 | */ | |
452 | ||
453 | ||
454 | ||
0cda46cf | 455 | /* |
326e32d7 | 456 | FUNCTION |
0cda46cf SC |
457 | bfd_perform_relocation |
458 | ||
e98e6ec1 SC |
459 | SYNOPSIS |
460 | bfd_reloc_status_type | |
461 | bfd_perform_relocation | |
c188b0be | 462 | (bfd *abfd, |
4c3721d5 ILT |
463 | arelent *reloc_entry, |
464 | PTR data, | |
465 | asection *input_section, | |
466 | bfd *output_bfd, | |
467 | char **error_message); | |
e98e6ec1 | 468 | |
0cda46cf | 469 | DESCRIPTION |
4c3721d5 ILT |
470 | If @var{output_bfd} is supplied to this function, the |
471 | generated image will be relocatable; the relocations are | |
472 | copied to the output file after they have been changed to | |
473 | reflect the new state of the world. There are two ways of | |
474 | reflecting the results of partial linkage in an output file: | |
475 | by modifying the output data in place, and by modifying the | |
476 | relocation record. Some native formats (e.g., basic a.out and | |
477 | basic coff) have no way of specifying an addend in the | |
478 | relocation type, so the addend has to go in the output data. | |
479 | This is no big deal since in these formats the output data | |
480 | slot will always be big enough for the addend. Complex reloc | |
481 | types with addends were invented to solve just this problem. | |
482 | The @var{error_message} argument is set to an error message if | |
483 | this return @code{bfd_reloc_dangerous}. | |
0cda46cf | 484 | |
985fca12 SC |
485 | */ |
486 | ||
487 | ||
0cda46cf | 488 | bfd_reloc_status_type |
4c3721d5 ILT |
489 | bfd_perform_relocation (abfd, reloc_entry, data, input_section, output_bfd, |
490 | error_message) | |
491 | bfd *abfd; | |
492 | arelent *reloc_entry; | |
493 | PTR data; | |
494 | asection *input_section; | |
495 | bfd *output_bfd; | |
496 | char **error_message; | |
985fca12 SC |
497 | { |
498 | bfd_vma relocation; | |
0cda46cf | 499 | bfd_reloc_status_type flag = bfd_reloc_ok; |
326e32d7 | 500 | bfd_size_type addr = reloc_entry->address; |
985fca12 | 501 | bfd_vma output_base = 0; |
82b1edf7 | 502 | reloc_howto_type *howto = reloc_entry->howto; |
4c3721d5 | 503 | asection *reloc_target_output_section; |
985fca12 SC |
504 | asymbol *symbol; |
505 | ||
4c3721d5 | 506 | symbol = *(reloc_entry->sym_ptr_ptr); |
1fb83be6 | 507 | if (bfd_is_abs_section (symbol->section) |
326e32d7 | 508 | && output_bfd != (bfd *) NULL) |
58acdbd7 KR |
509 | { |
510 | reloc_entry->address += input_section->output_offset; | |
511 | return bfd_reloc_ok; | |
512 | } | |
513 | ||
fb32909a KR |
514 | /* If we are not producing relocateable output, return an error if |
515 | the symbol is not defined. An undefined weak symbol is | |
516 | considered to have a value of zero (SVR4 ABI, p. 4-27). */ | |
1fb83be6 | 517 | if (bfd_is_und_section (symbol->section) |
fb32909a KR |
518 | && (symbol->flags & BSF_WEAK) == 0 |
519 | && output_bfd == (bfd *) NULL) | |
5022aea5 | 520 | flag = bfd_reloc_undefined; |
985fca12 | 521 | |
58acdbd7 KR |
522 | /* If there is a function supplied to handle this relocation type, |
523 | call it. It'll return `bfd_reloc_continue' if further processing | |
524 | can be done. */ | |
525 | if (howto->special_function) | |
526 | { | |
527 | bfd_reloc_status_type cont; | |
528 | cont = howto->special_function (abfd, reloc_entry, symbol, data, | |
4c3721d5 ILT |
529 | input_section, output_bfd, |
530 | error_message); | |
58acdbd7 KR |
531 | if (cont != bfd_reloc_continue) |
532 | return cont; | |
533 | } | |
985fca12 | 534 | |
58acdbd7 KR |
535 | /* Is the address of the relocation really within the section? */ |
536 | if (reloc_entry->address > input_section->_cooked_size) | |
537 | return bfd_reloc_outofrange; | |
985fca12 | 538 | |
58acdbd7 KR |
539 | /* Work out which section the relocation is targetted at and the |
540 | initial relocation command value. */ | |
541 | ||
542 | /* Get symbol value. (Common symbols are special.) */ | |
543 | if (bfd_is_com_section (symbol->section)) | |
5022aea5 | 544 | relocation = 0; |
58acdbd7 | 545 | else |
5022aea5 | 546 | relocation = symbol->value; |
985fca12 | 547 | |
985fca12 | 548 | |
e98e6ec1 | 549 | reloc_target_output_section = symbol->section->output_section; |
985fca12 | 550 | |
58acdbd7 | 551 | /* Convert input-section-relative symbol value to absolute. */ |
326e32d7 | 552 | if (output_bfd && howto->partial_inplace == false) |
5022aea5 | 553 | output_base = 0; |
58acdbd7 | 554 | else |
5022aea5 | 555 | output_base = reloc_target_output_section->vma; |
985fca12 | 556 | |
65cab589 | 557 | relocation += output_base + symbol->section->output_offset; |
985fca12 | 558 | |
58acdbd7 | 559 | /* Add in supplied addend. */ |
65cab589 | 560 | relocation += reloc_entry->addend; |
985fca12 | 561 | |
c188b0be DM |
562 | /* Here the variable relocation holds the final address of the |
563 | symbol we are relocating against, plus any addend. */ | |
564 | ||
985fca12 | 565 | if (howto->pc_relative == true) |
58acdbd7 | 566 | { |
c188b0be DM |
567 | /* This is a PC relative relocation. We want to set RELOCATION |
568 | to the distance between the address of the symbol and the | |
569 | location. RELOCATION is already the address of the symbol. | |
570 | ||
571 | We start by subtracting the address of the section containing | |
572 | the location. | |
573 | ||
574 | If pcrel_offset is set, we must further subtract the position | |
575 | of the location within the section. Some targets arrange for | |
576 | the addend to be the negative of the position of the location | |
577 | within the section; for example, i386-aout does this. For | |
578 | i386-aout, pcrel_offset is false. Some other targets do not | |
579 | include the position of the location; for example, m88kbcs, | |
580 | or ELF. For those targets, pcrel_offset is true. | |
581 | ||
582 | If we are producing relocateable output, then we must ensure | |
583 | that this reloc will be correctly computed when the final | |
584 | relocation is done. If pcrel_offset is false we want to wind | |
585 | up with the negative of the location within the section, | |
586 | which means we must adjust the existing addend by the change | |
587 | in the location within the section. If pcrel_offset is true | |
588 | we do not want to adjust the existing addend at all. | |
589 | ||
590 | FIXME: This seems logical to me, but for the case of | |
591 | producing relocateable output it is not what the code | |
592 | actually does. I don't want to change it, because it seems | |
593 | far too likely that something will break. */ | |
985fca12 | 594 | |
326e32d7 | 595 | relocation -= |
58acdbd7 KR |
596 | input_section->output_section->vma + input_section->output_offset; |
597 | ||
598 | if (howto->pcrel_offset == true) | |
599 | relocation -= reloc_entry->address; | |
5022aea5 | 600 | } |
e98e6ec1 | 601 | |
326e32d7 | 602 | if (output_bfd != (bfd *) NULL) |
5022aea5 | 603 | { |
326e32d7 | 604 | if (howto->partial_inplace == false) |
58acdbd7 KR |
605 | { |
606 | /* This is a partial relocation, and we want to apply the relocation | |
607 | to the reloc entry rather than the raw data. Modify the reloc | |
608 | inplace to reflect what we now know. */ | |
609 | reloc_entry->addend = relocation; | |
326e32d7 | 610 | reloc_entry->address += input_section->output_offset; |
58acdbd7 KR |
611 | return flag; |
612 | } | |
c26d7d17 | 613 | else |
58acdbd7 KR |
614 | { |
615 | /* This is a partial relocation, but inplace, so modify the | |
326e32d7 | 616 | reloc record a bit. |
58acdbd7 KR |
617 | |
618 | If we've relocated with a symbol with a section, change | |
619 | into a ref to the section belonging to the symbol. */ | |
620 | ||
621 | reloc_entry->address += input_section->output_offset; | |
622 | ||
623 | /* WTF?? */ | |
3d51f02f | 624 | if (abfd->xvec->flavour == bfd_target_coff_flavour |
1fb83be6 | 625 | && strcmp (abfd->xvec->name, "aixcoff-rs6000") != 0 |
50bd50d4 | 626 | && strcmp (abfd->xvec->name, "xcoff-powermac") != 0 |
1fb83be6 KR |
627 | && strcmp (abfd->xvec->name, "coff-Intel-little") != 0 |
628 | && strcmp (abfd->xvec->name, "coff-Intel-big") != 0) | |
58acdbd7 | 629 | { |
c188b0be DM |
630 | #if 1 |
631 | /* For m68k-coff, the addend was being subtracted twice during | |
632 | relocation with -r. Removing the line below this comment | |
633 | fixes that problem; see PR 2953. | |
634 | ||
635 | However, Ian wrote the following, regarding removing the line below, | |
636 | which explains why it is still enabled: --djm | |
637 | ||
638 | If you put a patch like that into BFD you need to check all the COFF | |
639 | linkers. I am fairly certain that patch will break coff-i386 (e.g., | |
640 | SCO); see coff_i386_reloc in coff-i386.c where I worked around the | |
641 | problem in a different way. There may very well be a reason that the | |
642 | code works as it does. | |
643 | ||
644 | Hmmm. The first obvious point is that bfd_perform_relocation should | |
645 | not have any tests that depend upon the flavour. It's seem like | |
646 | entirely the wrong place for such a thing. The second obvious point | |
647 | is that the current code ignores the reloc addend when producing | |
648 | relocateable output for COFF. That's peculiar. In fact, I really | |
649 | have no idea what the point of the line you want to remove is. | |
650 | ||
651 | A typical COFF reloc subtracts the old value of the symbol and adds in | |
652 | the new value to the location in the object file (if it's a pc | |
653 | relative reloc it adds the difference between the symbol value and the | |
654 | location). When relocating we need to preserve that property. | |
655 | ||
656 | BFD handles this by setting the addend to the negative of the old | |
657 | value of the symbol. Unfortunately it handles common symbols in a | |
658 | non-standard way (it doesn't subtract the old value) but that's a | |
659 | different story (we can't change it without losing backward | |
660 | compatibility with old object files) (coff-i386 does subtract the old | |
661 | value, to be compatible with existing coff-i386 targets, like SCO). | |
662 | ||
663 | So everything works fine when not producing relocateable output. When | |
664 | we are producing relocateable output, logically we should do exactly | |
665 | what we do when not producing relocateable output. Therefore, your | |
666 | patch is correct. In fact, it should probably always just set | |
667 | reloc_entry->addend to 0 for all cases, since it is, in fact, going to | |
668 | add the value into the object file. This won't hurt the COFF code, | |
669 | which doesn't use the addend; I'm not sure what it will do to other | |
670 | formats (the thing to check for would be whether any formats both use | |
671 | the addend and set partial_inplace). | |
672 | ||
673 | When I wanted to make coff-i386 produce relocateable output, I ran | |
674 | into the problem that you are running into: I wanted to remove that | |
675 | line. Rather than risk it, I made the coff-i386 relocs use a special | |
676 | function; it's coff_i386_reloc in coff-i386.c. The function | |
677 | specifically adds the addend field into the object file, knowing that | |
678 | bfd_perform_relocation is not going to. If you remove that line, then | |
679 | coff-i386.c will wind up adding the addend field in twice. It's | |
680 | trivial to fix; it just needs to be done. | |
681 | ||
682 | The problem with removing the line is just that it may break some | |
683 | working code. With BFD it's hard to be sure of anything. The right | |
684 | way to deal with this is simply to build and test at least all the | |
685 | supported COFF targets. It should be straightforward if time and disk | |
686 | space consuming. For each target: | |
687 | 1) build the linker | |
688 | 2) generate some executable, and link it using -r (I would | |
689 | probably use paranoia.o and link against newlib/libc.a, which | |
690 | for all the supported targets would be available in | |
691 | /usr/cygnus/progressive/H-host/target/lib/libc.a). | |
692 | 3) make the change to reloc.c | |
693 | 4) rebuild the linker | |
694 | 5) repeat step 2 | |
695 | 6) if the resulting object files are the same, you have at least | |
696 | made it no worse | |
697 | 7) if they are different you have to figure out which version is | |
698 | right | |
699 | */ | |
58acdbd7 | 700 | relocation -= reloc_entry->addend; |
c188b0be | 701 | #endif |
58acdbd7 KR |
702 | reloc_entry->addend = 0; |
703 | } | |
704 | else | |
705 | { | |
706 | reloc_entry->addend = relocation; | |
707 | } | |
708 | } | |
985fca12 | 709 | } |
326e32d7 | 710 | else |
58acdbd7 KR |
711 | { |
712 | reloc_entry->addend = 0; | |
713 | } | |
985fca12 | 714 | |
66a277ab ILT |
715 | /* FIXME: This overflow checking is incomplete, because the value |
716 | might have overflowed before we get here. For a correct check we | |
717 | need to compute the value in a size larger than bitsize, but we | |
718 | can't reasonably do that for a reloc the same size as a host | |
a49880c8 KR |
719 | machine word. |
720 | FIXME: We should also do overflow checking on the result after | |
721 | adding in the value contained in the object file. */ | |
e9f03cd4 ILT |
722 | if (howto->complain_on_overflow != complain_overflow_dont |
723 | && flag == bfd_reloc_ok) | |
65cab589 | 724 | { |
109a640b KR |
725 | bfd_vma check; |
726 | ||
727 | /* Get the value that will be used for the relocation, but | |
728 | starting at bit position zero. */ | |
e9f03cd4 | 729 | check = relocation >> howto->rightshift; |
109a640b KR |
730 | switch (howto->complain_on_overflow) |
731 | { | |
732 | case complain_overflow_signed: | |
733 | { | |
734 | /* Assumes two's complement. */ | |
735 | bfd_signed_vma reloc_signed_max = (1 << (howto->bitsize - 1)) - 1; | |
326e32d7 | 736 | bfd_signed_vma reloc_signed_min = ~reloc_signed_max; |
109a640b KR |
737 | |
738 | /* The above right shift is incorrect for a signed value. | |
739 | Fix it up by forcing on the upper bits. */ | |
e9f03cd4 | 740 | if (howto->rightshift > 0 |
109a640b | 741 | && (bfd_signed_vma) relocation < 0) |
326e32d7 ILT |
742 | check |= ((bfd_vma) - 1 |
743 | & ~((bfd_vma) - 1 | |
e9f03cd4 | 744 | >> howto->rightshift)); |
109a640b KR |
745 | if ((bfd_signed_vma) check > reloc_signed_max |
746 | || (bfd_signed_vma) check < reloc_signed_min) | |
747 | flag = bfd_reloc_overflow; | |
748 | } | |
749 | break; | |
750 | case complain_overflow_unsigned: | |
751 | { | |
752 | /* Assumes two's complement. This expression avoids | |
753 | overflow if howto->bitsize is the number of bits in | |
754 | bfd_vma. */ | |
755 | bfd_vma reloc_unsigned_max = | |
326e32d7 | 756 | (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; |
109a640b KR |
757 | |
758 | if ((bfd_vma) check > reloc_unsigned_max) | |
759 | flag = bfd_reloc_overflow; | |
760 | } | |
761 | break; | |
762 | case complain_overflow_bitfield: | |
763 | { | |
764 | /* Assumes two's complement. This expression avoids | |
765 | overflow if howto->bitsize is the number of bits in | |
766 | bfd_vma. */ | |
767 | bfd_vma reloc_bits = (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; | |
768 | ||
326e32d7 ILT |
769 | if (((bfd_vma) check & ~reloc_bits) != 0 |
770 | && ((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits)) | |
a49880c8 KR |
771 | { |
772 | /* The above right shift is incorrect for a signed | |
773 | value. See if turning on the upper bits fixes the | |
774 | overflow. */ | |
e9f03cd4 | 775 | if (howto->rightshift > 0 |
a49880c8 KR |
776 | && (bfd_signed_vma) relocation < 0) |
777 | { | |
326e32d7 ILT |
778 | check |= ((bfd_vma) - 1 |
779 | & ~((bfd_vma) - 1 | |
e9f03cd4 | 780 | >> howto->rightshift)); |
326e32d7 | 781 | if (((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits)) |
a49880c8 KR |
782 | flag = bfd_reloc_overflow; |
783 | } | |
784 | else | |
785 | flag = bfd_reloc_overflow; | |
786 | } | |
109a640b KR |
787 | } |
788 | break; | |
789 | default: | |
790 | abort (); | |
791 | } | |
65cab589 | 792 | } |
326e32d7 ILT |
793 | |
794 | /* | |
985fca12 SC |
795 | Either we are relocating all the way, or we don't want to apply |
796 | the relocation to the reloc entry (probably because there isn't | |
797 | any room in the output format to describe addends to relocs) | |
798 | */ | |
c188b0be DM |
799 | |
800 | /* The cast to bfd_vma avoids a bug in the Alpha OSF/1 C compiler | |
801 | (OSF version 1.3, compiler version 3.11). It miscompiles the | |
802 | following program: | |
803 | ||
804 | struct str | |
805 | { | |
806 | unsigned int i0; | |
807 | } s = { 0 }; | |
808 | ||
809 | int | |
810 | main () | |
811 | { | |
812 | unsigned long x; | |
813 | ||
814 | x = 0x100000000; | |
815 | x <<= (unsigned long) s.i0; | |
816 | if (x == 0) | |
817 | printf ("failed\n"); | |
818 | else | |
819 | printf ("succeeded (%lx)\n", x); | |
820 | } | |
821 | */ | |
822 | ||
823 | relocation >>= (bfd_vma) howto->rightshift; | |
985fca12 SC |
824 | |
825 | /* Shift everything up to where it's going to be used */ | |
326e32d7 | 826 | |
c188b0be | 827 | relocation <<= (bfd_vma) howto->bitpos; |
985fca12 SC |
828 | |
829 | /* Wait for the day when all have the mask in them */ | |
830 | ||
831 | /* What we do: | |
832 | i instruction to be left alone | |
833 | o offset within instruction | |
834 | r relocation offset to apply | |
835 | S src mask | |
836 | D dst mask | |
837 | N ~dst mask | |
838 | A part 1 | |
839 | B part 2 | |
840 | R result | |
326e32d7 | 841 | |
985fca12 SC |
842 | Do this: |
843 | i i i i i o o o o o from bfd_get<size> | |
844 | and S S S S S to get the size offset we want | |
845 | + r r r r r r r r r r to get the final value to place | |
846 | and D D D D D to chop to right size | |
847 | ----------------------- | |
326e32d7 | 848 | A A A A A |
985fca12 SC |
849 | And this: |
850 | ... i i i i i o o o o o from bfd_get<size> | |
851 | and N N N N N get instruction | |
852 | ----------------------- | |
853 | ... B B B B B | |
326e32d7 ILT |
854 | |
855 | And then: | |
856 | B B B B B | |
857 | or A A A A A | |
985fca12 SC |
858 | ----------------------- |
859 | R R R R R R R R R R put into bfd_put<size> | |
860 | */ | |
861 | ||
862 | #define DOIT(x) \ | |
863 | x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask)) | |
864 | ||
326e32d7 ILT |
865 | switch (howto->size) |
866 | { | |
867 | case 0: | |
868 | { | |
869 | char x = bfd_get_8 (abfd, (char *) data + addr); | |
870 | DOIT (x); | |
871 | bfd_put_8 (abfd, x, (unsigned char *) data + addr); | |
872 | } | |
873 | break; | |
874 | ||
875 | case 1: | |
a5a43df1 ILT |
876 | { |
877 | short x = bfd_get_16 (abfd, (bfd_byte *) data + addr); | |
878 | DOIT (x); | |
879 | bfd_put_16 (abfd, x, (unsigned char *) data + addr); | |
880 | } | |
326e32d7 ILT |
881 | break; |
882 | case 2: | |
a5a43df1 ILT |
883 | { |
884 | long x = bfd_get_32 (abfd, (bfd_byte *) data + addr); | |
885 | DOIT (x); | |
886 | bfd_put_32 (abfd, x, (bfd_byte *) data + addr); | |
887 | } | |
326e32d7 ILT |
888 | break; |
889 | case -2: | |
890 | { | |
891 | long x = bfd_get_32 (abfd, (bfd_byte *) data + addr); | |
892 | relocation = -relocation; | |
893 | DOIT (x); | |
894 | bfd_put_32 (abfd, x, (bfd_byte *) data + addr); | |
895 | } | |
896 | break; | |
897 | ||
e9f03cd4 ILT |
898 | case -1: |
899 | { | |
900 | long x = bfd_get_16 (abfd, (bfd_byte *) data + addr); | |
901 | relocation = -relocation; | |
902 | DOIT (x); | |
903 | bfd_put_16 (abfd, x, (bfd_byte *) data + addr); | |
904 | } | |
905 | break; | |
906 | ||
326e32d7 ILT |
907 | case 3: |
908 | /* Do nothing */ | |
909 | break; | |
910 | ||
911 | case 4: | |
109a640b | 912 | #ifdef BFD64 |
a5a43df1 ILT |
913 | { |
914 | bfd_vma x = bfd_get_64 (abfd, (bfd_byte *) data + addr); | |
915 | DOIT (x); | |
916 | bfd_put_64 (abfd, x, (bfd_byte *) data + addr); | |
917 | } | |
109a640b | 918 | #else |
326e32d7 | 919 | abort (); |
109a640b | 920 | #endif |
326e32d7 ILT |
921 | break; |
922 | default: | |
923 | return bfd_reloc_other; | |
924 | } | |
985fca12 SC |
925 | |
926 | return flag; | |
927 | } | |
c618de01 | 928 | |
094e8be3 ILT |
929 | /* |
930 | FUNCTION | |
931 | bfd_install_relocation | |
932 | ||
933 | SYNOPSIS | |
934 | bfd_reloc_status_type | |
935 | bfd_install_relocation | |
936 | (bfd *abfd, | |
937 | arelent *reloc_entry, | |
938 | PTR data, bfd_vma data_start, | |
939 | asection *input_section, | |
940 | char **error_message); | |
941 | ||
942 | DESCRIPTION | |
943 | This looks remarkably like <<bfd_perform_relocation>>, except it | |
944 | does not expect that the section contents have been filled in. | |
945 | I.e., it's suitable for use when creating, rather than applying | |
946 | a relocation. | |
947 | ||
948 | For now, this function should be considered reserved for the | |
949 | assembler. | |
950 | ||
951 | */ | |
952 | ||
953 | ||
954 | bfd_reloc_status_type | |
955 | bfd_install_relocation (abfd, reloc_entry, data_start, data_start_offset, | |
956 | input_section, error_message) | |
957 | bfd *abfd; | |
958 | arelent *reloc_entry; | |
959 | PTR data_start; | |
960 | bfd_vma data_start_offset; | |
961 | asection *input_section; | |
962 | char **error_message; | |
963 | { | |
964 | bfd_vma relocation; | |
965 | bfd_reloc_status_type flag = bfd_reloc_ok; | |
966 | bfd_size_type addr = reloc_entry->address; | |
967 | bfd_vma output_base = 0; | |
82b1edf7 | 968 | reloc_howto_type *howto = reloc_entry->howto; |
094e8be3 ILT |
969 | asection *reloc_target_output_section; |
970 | asymbol *symbol; | |
fca2b81b | 971 | bfd_byte *data; |
094e8be3 ILT |
972 | |
973 | symbol = *(reloc_entry->sym_ptr_ptr); | |
974 | if (bfd_is_abs_section (symbol->section)) | |
975 | { | |
976 | reloc_entry->address += input_section->output_offset; | |
977 | return bfd_reloc_ok; | |
978 | } | |
979 | ||
980 | /* If there is a function supplied to handle this relocation type, | |
981 | call it. It'll return `bfd_reloc_continue' if further processing | |
982 | can be done. */ | |
983 | if (howto->special_function) | |
984 | { | |
985 | bfd_reloc_status_type cont; | |
986 | /* XXX - The special_function calls haven't been fixed up to deal | |
987 | with creating new relocations and section contents. */ | |
988 | cont = howto->special_function (abfd, reloc_entry, symbol, | |
989 | /* XXX - Non-portable! */ | |
990 | ((bfd_byte *) data_start | |
991 | - data_start_offset), | |
992 | input_section, abfd, error_message); | |
993 | if (cont != bfd_reloc_continue) | |
994 | return cont; | |
995 | } | |
996 | ||
997 | /* Is the address of the relocation really within the section? */ | |
998 | if (reloc_entry->address > input_section->_cooked_size) | |
999 | return bfd_reloc_outofrange; | |
1000 | ||
1001 | /* Work out which section the relocation is targetted at and the | |
1002 | initial relocation command value. */ | |
1003 | ||
1004 | /* Get symbol value. (Common symbols are special.) */ | |
1005 | if (bfd_is_com_section (symbol->section)) | |
1006 | relocation = 0; | |
1007 | else | |
1008 | relocation = symbol->value; | |
1009 | ||
1010 | ||
1011 | reloc_target_output_section = symbol->section->output_section; | |
1012 | ||
1013 | /* Convert input-section-relative symbol value to absolute. */ | |
1014 | if (howto->partial_inplace == false) | |
1015 | output_base = 0; | |
1016 | else | |
1017 | output_base = reloc_target_output_section->vma; | |
1018 | ||
1019 | relocation += output_base + symbol->section->output_offset; | |
1020 | ||
1021 | /* Add in supplied addend. */ | |
1022 | relocation += reloc_entry->addend; | |
1023 | ||
1024 | /* Here the variable relocation holds the final address of the | |
1025 | symbol we are relocating against, plus any addend. */ | |
1026 | ||
1027 | if (howto->pc_relative == true) | |
1028 | { | |
1029 | /* This is a PC relative relocation. We want to set RELOCATION | |
1030 | to the distance between the address of the symbol and the | |
1031 | location. RELOCATION is already the address of the symbol. | |
1032 | ||
1033 | We start by subtracting the address of the section containing | |
1034 | the location. | |
1035 | ||
1036 | If pcrel_offset is set, we must further subtract the position | |
1037 | of the location within the section. Some targets arrange for | |
1038 | the addend to be the negative of the position of the location | |
1039 | within the section; for example, i386-aout does this. For | |
1040 | i386-aout, pcrel_offset is false. Some other targets do not | |
1041 | include the position of the location; for example, m88kbcs, | |
1042 | or ELF. For those targets, pcrel_offset is true. | |
1043 | ||
1044 | If we are producing relocateable output, then we must ensure | |
1045 | that this reloc will be correctly computed when the final | |
1046 | relocation is done. If pcrel_offset is false we want to wind | |
1047 | up with the negative of the location within the section, | |
1048 | which means we must adjust the existing addend by the change | |
1049 | in the location within the section. If pcrel_offset is true | |
1050 | we do not want to adjust the existing addend at all. | |
1051 | ||
1052 | FIXME: This seems logical to me, but for the case of | |
1053 | producing relocateable output it is not what the code | |
1054 | actually does. I don't want to change it, because it seems | |
1055 | far too likely that something will break. */ | |
1056 | ||
1057 | relocation -= | |
1058 | input_section->output_section->vma + input_section->output_offset; | |
1059 | ||
1060 | if (howto->pcrel_offset == true && howto->partial_inplace == true) | |
1061 | relocation -= reloc_entry->address; | |
1062 | } | |
1063 | ||
1064 | if (howto->partial_inplace == false) | |
1065 | { | |
1066 | /* This is a partial relocation, and we want to apply the relocation | |
1067 | to the reloc entry rather than the raw data. Modify the reloc | |
1068 | inplace to reflect what we now know. */ | |
1069 | reloc_entry->addend = relocation; | |
1070 | reloc_entry->address += input_section->output_offset; | |
1071 | return flag; | |
1072 | } | |
1073 | else | |
1074 | { | |
1075 | /* This is a partial relocation, but inplace, so modify the | |
1076 | reloc record a bit. | |
6b31fd3a | 1077 | |
094e8be3 ILT |
1078 | If we've relocated with a symbol with a section, change |
1079 | into a ref to the section belonging to the symbol. */ | |
6b31fd3a | 1080 | |
094e8be3 | 1081 | reloc_entry->address += input_section->output_offset; |
6b31fd3a | 1082 | |
094e8be3 ILT |
1083 | /* WTF?? */ |
1084 | if (abfd->xvec->flavour == bfd_target_coff_flavour | |
1085 | && strcmp (abfd->xvec->name, "aixcoff-rs6000") != 0 | |
50bd50d4 | 1086 | && strcmp (abfd->xvec->name, "xcoff-powermac") != 0 |
094e8be3 ILT |
1087 | && strcmp (abfd->xvec->name, "coff-Intel-little") != 0 |
1088 | && strcmp (abfd->xvec->name, "coff-Intel-big") != 0) | |
1089 | { | |
1090 | #if 1 | |
1091 | /* For m68k-coff, the addend was being subtracted twice during | |
1092 | relocation with -r. Removing the line below this comment | |
1093 | fixes that problem; see PR 2953. | |
6b31fd3a | 1094 | |
094e8be3 ILT |
1095 | However, Ian wrote the following, regarding removing the line below, |
1096 | which explains why it is still enabled: --djm | |
6b31fd3a | 1097 | |
094e8be3 ILT |
1098 | If you put a patch like that into BFD you need to check all the COFF |
1099 | linkers. I am fairly certain that patch will break coff-i386 (e.g., | |
1100 | SCO); see coff_i386_reloc in coff-i386.c where I worked around the | |
1101 | problem in a different way. There may very well be a reason that the | |
1102 | code works as it does. | |
1103 | ||
1104 | Hmmm. The first obvious point is that bfd_install_relocation should | |
1105 | not have any tests that depend upon the flavour. It's seem like | |
1106 | entirely the wrong place for such a thing. The second obvious point | |
1107 | is that the current code ignores the reloc addend when producing | |
1108 | relocateable output for COFF. That's peculiar. In fact, I really | |
1109 | have no idea what the point of the line you want to remove is. | |
1110 | ||
1111 | A typical COFF reloc subtracts the old value of the symbol and adds in | |
1112 | the new value to the location in the object file (if it's a pc | |
1113 | relative reloc it adds the difference between the symbol value and the | |
1114 | location). When relocating we need to preserve that property. | |
1115 | ||
1116 | BFD handles this by setting the addend to the negative of the old | |
1117 | value of the symbol. Unfortunately it handles common symbols in a | |
1118 | non-standard way (it doesn't subtract the old value) but that's a | |
1119 | different story (we can't change it without losing backward | |
1120 | compatibility with old object files) (coff-i386 does subtract the old | |
1121 | value, to be compatible with existing coff-i386 targets, like SCO). | |
1122 | ||
1123 | So everything works fine when not producing relocateable output. When | |
1124 | we are producing relocateable output, logically we should do exactly | |
1125 | what we do when not producing relocateable output. Therefore, your | |
1126 | patch is correct. In fact, it should probably always just set | |
1127 | reloc_entry->addend to 0 for all cases, since it is, in fact, going to | |
1128 | add the value into the object file. This won't hurt the COFF code, | |
1129 | which doesn't use the addend; I'm not sure what it will do to other | |
1130 | formats (the thing to check for would be whether any formats both use | |
1131 | the addend and set partial_inplace). | |
1132 | ||
1133 | When I wanted to make coff-i386 produce relocateable output, I ran | |
1134 | into the problem that you are running into: I wanted to remove that | |
1135 | line. Rather than risk it, I made the coff-i386 relocs use a special | |
1136 | function; it's coff_i386_reloc in coff-i386.c. The function | |
1137 | specifically adds the addend field into the object file, knowing that | |
1138 | bfd_install_relocation is not going to. If you remove that line, then | |
1139 | coff-i386.c will wind up adding the addend field in twice. It's | |
1140 | trivial to fix; it just needs to be done. | |
1141 | ||
1142 | The problem with removing the line is just that it may break some | |
1143 | working code. With BFD it's hard to be sure of anything. The right | |
1144 | way to deal with this is simply to build and test at least all the | |
1145 | supported COFF targets. It should be straightforward if time and disk | |
1146 | space consuming. For each target: | |
1147 | 1) build the linker | |
1148 | 2) generate some executable, and link it using -r (I would | |
1149 | probably use paranoia.o and link against newlib/libc.a, which | |
1150 | for all the supported targets would be available in | |
1151 | /usr/cygnus/progressive/H-host/target/lib/libc.a). | |
1152 | 3) make the change to reloc.c | |
1153 | 4) rebuild the linker | |
1154 | 5) repeat step 2 | |
1155 | 6) if the resulting object files are the same, you have at least | |
1156 | made it no worse | |
1157 | 7) if they are different you have to figure out which version is | |
1158 | right | |
1159 | */ | |
1160 | relocation -= reloc_entry->addend; | |
1161 | #endif | |
1162 | reloc_entry->addend = 0; | |
1163 | } | |
1164 | else | |
1165 | { | |
1166 | reloc_entry->addend = relocation; | |
1167 | } | |
1168 | } | |
1169 | ||
1170 | /* FIXME: This overflow checking is incomplete, because the value | |
1171 | might have overflowed before we get here. For a correct check we | |
1172 | need to compute the value in a size larger than bitsize, but we | |
1173 | can't reasonably do that for a reloc the same size as a host | |
1174 | machine word. | |
1175 | ||
1176 | FIXME: We should also do overflow checking on the result after | |
1177 | adding in the value contained in the object file. */ | |
1178 | if (howto->complain_on_overflow != complain_overflow_dont) | |
1179 | { | |
1180 | bfd_vma check; | |
1181 | ||
1182 | /* Get the value that will be used for the relocation, but | |
1183 | starting at bit position zero. */ | |
e9f03cd4 | 1184 | check = relocation >> howto->rightshift; |
094e8be3 ILT |
1185 | switch (howto->complain_on_overflow) |
1186 | { | |
1187 | case complain_overflow_signed: | |
1188 | { | |
1189 | /* Assumes two's complement. */ | |
1190 | bfd_signed_vma reloc_signed_max = (1 << (howto->bitsize - 1)) - 1; | |
1191 | bfd_signed_vma reloc_signed_min = ~reloc_signed_max; | |
1192 | ||
1193 | /* The above right shift is incorrect for a signed value. | |
1194 | Fix it up by forcing on the upper bits. */ | |
e9f03cd4 | 1195 | if (howto->rightshift > 0 |
094e8be3 ILT |
1196 | && (bfd_signed_vma) relocation < 0) |
1197 | check |= ((bfd_vma) - 1 | |
1198 | & ~((bfd_vma) - 1 | |
e9f03cd4 | 1199 | >> howto->rightshift)); |
094e8be3 ILT |
1200 | if ((bfd_signed_vma) check > reloc_signed_max |
1201 | || (bfd_signed_vma) check < reloc_signed_min) | |
1202 | flag = bfd_reloc_overflow; | |
1203 | } | |
1204 | break; | |
1205 | case complain_overflow_unsigned: | |
1206 | { | |
1207 | /* Assumes two's complement. This expression avoids | |
1208 | overflow if howto->bitsize is the number of bits in | |
1209 | bfd_vma. */ | |
1210 | bfd_vma reloc_unsigned_max = | |
1211 | (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; | |
1212 | ||
1213 | if ((bfd_vma) check > reloc_unsigned_max) | |
1214 | flag = bfd_reloc_overflow; | |
1215 | } | |
1216 | break; | |
1217 | case complain_overflow_bitfield: | |
1218 | { | |
1219 | /* Assumes two's complement. This expression avoids | |
1220 | overflow if howto->bitsize is the number of bits in | |
1221 | bfd_vma. */ | |
1222 | bfd_vma reloc_bits = (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; | |
1223 | ||
1224 | if (((bfd_vma) check & ~reloc_bits) != 0 | |
1225 | && ((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits)) | |
1226 | { | |
1227 | /* The above right shift is incorrect for a signed | |
1228 | value. See if turning on the upper bits fixes the | |
1229 | overflow. */ | |
e9f03cd4 | 1230 | if (howto->rightshift > 0 |
094e8be3 ILT |
1231 | && (bfd_signed_vma) relocation < 0) |
1232 | { | |
1233 | check |= ((bfd_vma) - 1 | |
1234 | & ~((bfd_vma) - 1 | |
e9f03cd4 | 1235 | >> howto->rightshift)); |
094e8be3 ILT |
1236 | if (((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits)) |
1237 | flag = bfd_reloc_overflow; | |
1238 | } | |
1239 | else | |
1240 | flag = bfd_reloc_overflow; | |
1241 | } | |
1242 | } | |
1243 | break; | |
1244 | default: | |
1245 | abort (); | |
1246 | } | |
1247 | } | |
1248 | ||
1249 | /* | |
1250 | Either we are relocating all the way, or we don't want to apply | |
1251 | the relocation to the reloc entry (probably because there isn't | |
1252 | any room in the output format to describe addends to relocs) | |
1253 | */ | |
1254 | ||
1255 | /* The cast to bfd_vma avoids a bug in the Alpha OSF/1 C compiler | |
1256 | (OSF version 1.3, compiler version 3.11). It miscompiles the | |
1257 | following program: | |
1258 | ||
1259 | struct str | |
1260 | { | |
1261 | unsigned int i0; | |
1262 | } s = { 0 }; | |
1263 | ||
1264 | int | |
1265 | main () | |
1266 | { | |
1267 | unsigned long x; | |
1268 | ||
1269 | x = 0x100000000; | |
1270 | x <<= (unsigned long) s.i0; | |
1271 | if (x == 0) | |
1272 | printf ("failed\n"); | |
1273 | else | |
1274 | printf ("succeeded (%lx)\n", x); | |
1275 | } | |
1276 | */ | |
1277 | ||
1278 | relocation >>= (bfd_vma) howto->rightshift; | |
1279 | ||
1280 | /* Shift everything up to where it's going to be used */ | |
1281 | ||
1282 | relocation <<= (bfd_vma) howto->bitpos; | |
1283 | ||
1284 | /* Wait for the day when all have the mask in them */ | |
1285 | ||
1286 | /* What we do: | |
1287 | i instruction to be left alone | |
1288 | o offset within instruction | |
1289 | r relocation offset to apply | |
1290 | S src mask | |
1291 | D dst mask | |
1292 | N ~dst mask | |
1293 | A part 1 | |
1294 | B part 2 | |
1295 | R result | |
1296 | ||
1297 | Do this: | |
1298 | i i i i i o o o o o from bfd_get<size> | |
1299 | and S S S S S to get the size offset we want | |
1300 | + r r r r r r r r r r to get the final value to place | |
1301 | and D D D D D to chop to right size | |
1302 | ----------------------- | |
1303 | A A A A A | |
1304 | And this: | |
1305 | ... i i i i i o o o o o from bfd_get<size> | |
1306 | and N N N N N get instruction | |
1307 | ----------------------- | |
1308 | ... B B B B B | |
1309 | ||
1310 | And then: | |
1311 | B B B B B | |
1312 | or A A A A A | |
1313 | ----------------------- | |
1314 | R R R R R R R R R R put into bfd_put<size> | |
1315 | */ | |
1316 | ||
1317 | #define DOIT(x) \ | |
1318 | x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask)) | |
1319 | ||
1320 | data = (bfd_byte *) data_start + (addr - data_start_offset); | |
1321 | ||
1322 | switch (howto->size) | |
1323 | { | |
1324 | case 0: | |
1325 | { | |
1326 | char x = bfd_get_8 (abfd, (char *) data); | |
1327 | DOIT (x); | |
1328 | bfd_put_8 (abfd, x, (unsigned char *) data); | |
1329 | } | |
1330 | break; | |
1331 | ||
1332 | case 1: | |
a5a43df1 ILT |
1333 | { |
1334 | short x = bfd_get_16 (abfd, (bfd_byte *) data); | |
1335 | DOIT (x); | |
1336 | bfd_put_16 (abfd, x, (unsigned char *) data); | |
1337 | } | |
094e8be3 ILT |
1338 | break; |
1339 | case 2: | |
a5a43df1 ILT |
1340 | { |
1341 | long x = bfd_get_32 (abfd, (bfd_byte *) data); | |
1342 | DOIT (x); | |
1343 | bfd_put_32 (abfd, x, (bfd_byte *) data); | |
1344 | } | |
094e8be3 ILT |
1345 | break; |
1346 | case -2: | |
1347 | { | |
1348 | long x = bfd_get_32 (abfd, (bfd_byte *) data); | |
1349 | relocation = -relocation; | |
1350 | DOIT (x); | |
1351 | bfd_put_32 (abfd, x, (bfd_byte *) data); | |
1352 | } | |
1353 | break; | |
1354 | ||
1355 | case 3: | |
1356 | /* Do nothing */ | |
1357 | break; | |
1358 | ||
1359 | case 4: | |
a5a43df1 ILT |
1360 | { |
1361 | bfd_vma x = bfd_get_64 (abfd, (bfd_byte *) data); | |
1362 | DOIT (x); | |
1363 | bfd_put_64 (abfd, x, (bfd_byte *) data); | |
1364 | } | |
094e8be3 ILT |
1365 | break; |
1366 | default: | |
1367 | return bfd_reloc_other; | |
1368 | } | |
1369 | ||
1370 | return flag; | |
1371 | } | |
1372 | ||
4c3721d5 ILT |
1373 | /* This relocation routine is used by some of the backend linkers. |
1374 | They do not construct asymbol or arelent structures, so there is no | |
1375 | reason for them to use bfd_perform_relocation. Also, | |
1376 | bfd_perform_relocation is so hacked up it is easier to write a new | |
1377 | function than to try to deal with it. | |
1378 | ||
1379 | This routine does a final relocation. It should not be used when | |
1380 | generating relocateable output. | |
1381 | ||
1382 | FIXME: This routine ignores any special_function in the HOWTO, | |
1383 | since the existing special_function values have been written for | |
1384 | bfd_perform_relocation. | |
1385 | ||
1386 | HOWTO is the reloc howto information. | |
1387 | INPUT_BFD is the BFD which the reloc applies to. | |
1388 | INPUT_SECTION is the section which the reloc applies to. | |
1389 | CONTENTS is the contents of the section. | |
1390 | ADDRESS is the address of the reloc within INPUT_SECTION. | |
1391 | VALUE is the value of the symbol the reloc refers to. | |
1392 | ADDEND is the addend of the reloc. */ | |
1393 | ||
1394 | bfd_reloc_status_type | |
1395 | _bfd_final_link_relocate (howto, input_bfd, input_section, contents, address, | |
326e32d7 | 1396 | value, addend) |
82b1edf7 | 1397 | reloc_howto_type *howto; |
4c3721d5 ILT |
1398 | bfd *input_bfd; |
1399 | asection *input_section; | |
1400 | bfd_byte *contents; | |
1401 | bfd_vma address; | |
1402 | bfd_vma value; | |
1403 | bfd_vma addend; | |
1404 | { | |
1405 | bfd_vma relocation; | |
c618de01 | 1406 | |
4c3721d5 | 1407 | /* Sanity check the address. */ |
50bd50d4 | 1408 | if (address > input_section->_raw_size) |
4c3721d5 ILT |
1409 | return bfd_reloc_outofrange; |
1410 | ||
1411 | /* This function assumes that we are dealing with a basic relocation | |
1412 | against a symbol. We want to compute the value of the symbol to | |
1413 | relocate to. This is just VALUE, the value of the symbol, plus | |
1414 | ADDEND, any addend associated with the reloc. */ | |
1415 | relocation = value + addend; | |
1416 | ||
1417 | /* If the relocation is PC relative, we want to set RELOCATION to | |
1418 | the distance between the symbol (currently in RELOCATION) and the | |
1419 | location we are relocating. Some targets (e.g., i386-aout) | |
1420 | arrange for the contents of the section to be the negative of the | |
1421 | offset of the location within the section; for such targets | |
1422 | pcrel_offset is false. Other targets (e.g., m88kbcs or ELF) | |
1423 | simply leave the contents of the section as zero; for such | |
1424 | targets pcrel_offset is true. If pcrel_offset is false we do not | |
1425 | need to subtract out the offset of the location within the | |
1426 | section (which is just ADDRESS). */ | |
1427 | if (howto->pc_relative) | |
1428 | { | |
1429 | relocation -= (input_section->output_section->vma | |
1430 | + input_section->output_offset); | |
1431 | if (howto->pcrel_offset) | |
1432 | relocation -= address; | |
1433 | } | |
326e32d7 | 1434 | |
4c3721d5 ILT |
1435 | return _bfd_relocate_contents (howto, input_bfd, relocation, |
1436 | contents + address); | |
1437 | } | |
1438 | ||
1439 | /* Relocate a given location using a given value and howto. */ | |
1440 | ||
1441 | bfd_reloc_status_type | |
1442 | _bfd_relocate_contents (howto, input_bfd, relocation, location) | |
82b1edf7 | 1443 | reloc_howto_type *howto; |
4c3721d5 ILT |
1444 | bfd *input_bfd; |
1445 | bfd_vma relocation; | |
1446 | bfd_byte *location; | |
1447 | { | |
1448 | int size; | |
1449 | bfd_vma x; | |
1450 | boolean overflow; | |
1451 | ||
1452 | /* If the size is negative, negate RELOCATION. This isn't very | |
1453 | general. */ | |
1454 | if (howto->size < 0) | |
326e32d7 | 1455 | relocation = -relocation; |
4c3721d5 ILT |
1456 | |
1457 | /* Get the value we are going to relocate. */ | |
1458 | size = bfd_get_reloc_size (howto); | |
1459 | switch (size) | |
1460 | { | |
1461 | default: | |
1462 | case 0: | |
1463 | abort (); | |
1464 | case 1: | |
1465 | x = bfd_get_8 (input_bfd, location); | |
1466 | break; | |
1467 | case 2: | |
1468 | x = bfd_get_16 (input_bfd, location); | |
1469 | break; | |
1470 | case 4: | |
1471 | x = bfd_get_32 (input_bfd, location); | |
1472 | break; | |
1473 | case 8: | |
1474 | #ifdef BFD64 | |
1475 | x = bfd_get_64 (input_bfd, location); | |
1476 | #else | |
1477 | abort (); | |
1478 | #endif | |
1479 | break; | |
1480 | } | |
1481 | ||
1482 | /* Check for overflow. FIXME: We may drop bits during the addition | |
1483 | which we don't check for. We must either check at every single | |
1484 | operation, which would be tedious, or we must do the computations | |
1485 | in a type larger than bfd_vma, which would be inefficient. */ | |
1486 | overflow = false; | |
1487 | if (howto->complain_on_overflow != complain_overflow_dont) | |
1488 | { | |
1489 | bfd_vma check; | |
1490 | bfd_signed_vma signed_check; | |
1491 | bfd_vma add; | |
563eb766 | 1492 | bfd_signed_vma signed_add; |
4c3721d5 ILT |
1493 | |
1494 | if (howto->rightshift == 0) | |
1495 | { | |
1496 | check = relocation; | |
1497 | signed_check = (bfd_signed_vma) relocation; | |
1498 | } | |
1499 | else | |
1500 | { | |
1501 | /* Drop unwanted bits from the value we are relocating to. */ | |
1502 | check = relocation >> howto->rightshift; | |
1503 | ||
1504 | /* If this is a signed value, the rightshift just dropped | |
1505 | leading 1 bits (assuming twos complement). */ | |
1506 | if ((bfd_signed_vma) relocation >= 0) | |
1507 | signed_check = check; | |
1508 | else | |
1509 | signed_check = (check | |
326e32d7 ILT |
1510 | | ((bfd_vma) - 1 |
1511 | & ~((bfd_vma) - 1 >> howto->rightshift))); | |
4c3721d5 ILT |
1512 | } |
1513 | ||
3d51f02f | 1514 | /* Get the value from the object file. */ |
4c3721d5 | 1515 | add = x & howto->src_mask; |
3d51f02f ILT |
1516 | |
1517 | /* Get the value from the object file with an appropriate sign. | |
1518 | The expression involving howto->src_mask isolates the upper | |
1519 | bit of src_mask. If that bit is set in the value we are | |
1520 | adding, it is negative, and we subtract out that number times | |
1521 | two. If src_mask includes the highest possible bit, then we | |
1522 | can not get the upper bit, but that does not matter since | |
1523 | signed_add needs no adjustment to become negative in that | |
1524 | case. */ | |
1525 | signed_add = add; | |
326e32d7 ILT |
1526 | if ((add & (((~howto->src_mask) >> 1) & howto->src_mask)) != 0) |
1527 | signed_add -= (((~howto->src_mask) >> 1) & howto->src_mask) << 1; | |
3d51f02f ILT |
1528 | |
1529 | /* Add the value from the object file, shifted so that it is a | |
1530 | straight number. */ | |
4c3721d5 ILT |
1531 | if (howto->bitpos == 0) |
1532 | { | |
1533 | check += add; | |
563eb766 | 1534 | signed_check += signed_add; |
4c3721d5 ILT |
1535 | } |
1536 | else | |
1537 | { | |
563eb766 | 1538 | check += add >> howto->bitpos; |
3d51f02f ILT |
1539 | |
1540 | /* For the signed case we use ADD, rather than SIGNED_ADD, | |
1541 | to avoid warnings from SVR4 cc. This is OK since we | |
1542 | explictly handle the sign bits. */ | |
563eb766 | 1543 | if (signed_add >= 0) |
3d51f02f | 1544 | signed_check += add >> howto->bitpos; |
563eb766 | 1545 | else |
3d51f02f | 1546 | signed_check += ((add >> howto->bitpos) |
326e32d7 ILT |
1547 | | ((bfd_vma) - 1 |
1548 | & ~((bfd_vma) - 1 >> howto->bitpos))); | |
4c3721d5 ILT |
1549 | } |
1550 | ||
1551 | switch (howto->complain_on_overflow) | |
1552 | { | |
1553 | case complain_overflow_signed: | |
1554 | { | |
1555 | /* Assumes two's complement. */ | |
1556 | bfd_signed_vma reloc_signed_max = (1 << (howto->bitsize - 1)) - 1; | |
326e32d7 | 1557 | bfd_signed_vma reloc_signed_min = ~reloc_signed_max; |
4c3721d5 ILT |
1558 | |
1559 | if (signed_check > reloc_signed_max | |
1560 | || signed_check < reloc_signed_min) | |
1561 | overflow = true; | |
1562 | } | |
1563 | break; | |
1564 | case complain_overflow_unsigned: | |
1565 | { | |
1566 | /* Assumes two's complement. This expression avoids | |
1567 | overflow if howto->bitsize is the number of bits in | |
1568 | bfd_vma. */ | |
1569 | bfd_vma reloc_unsigned_max = | |
326e32d7 | 1570 | (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; |
4c3721d5 ILT |
1571 | |
1572 | if (check > reloc_unsigned_max) | |
1573 | overflow = true; | |
1574 | } | |
1575 | break; | |
1576 | case complain_overflow_bitfield: | |
1577 | { | |
1578 | /* Assumes two's complement. This expression avoids | |
1579 | overflow if howto->bitsize is the number of bits in | |
1580 | bfd_vma. */ | |
1581 | bfd_vma reloc_bits = (((1 << (howto->bitsize - 1)) - 1) << 1) | 1; | |
1582 | ||
326e32d7 ILT |
1583 | if ((check & ~reloc_bits) != 0 |
1584 | && (((bfd_vma) signed_check & ~reloc_bits) | |
1585 | != (-1 & ~reloc_bits))) | |
4c3721d5 ILT |
1586 | overflow = true; |
1587 | } | |
1588 | break; | |
1589 | default: | |
1590 | abort (); | |
1591 | } | |
1592 | } | |
1593 | ||
1594 | /* Put RELOCATION in the right bits. */ | |
1595 | relocation >>= (bfd_vma) howto->rightshift; | |
1596 | relocation <<= (bfd_vma) howto->bitpos; | |
1597 | ||
1598 | /* Add RELOCATION to the right bits of X. */ | |
326e32d7 | 1599 | x = ((x & ~howto->dst_mask) |
4c3721d5 ILT |
1600 | | (((x & howto->src_mask) + relocation) & howto->dst_mask)); |
1601 | ||
1602 | /* Put the relocated value back in the object file. */ | |
1603 | switch (size) | |
1604 | { | |
1605 | default: | |
1606 | case 0: | |
1607 | abort (); | |
1608 | case 1: | |
1609 | bfd_put_8 (input_bfd, x, location); | |
1610 | break; | |
1611 | case 2: | |
1612 | bfd_put_16 (input_bfd, x, location); | |
1613 | break; | |
1614 | case 4: | |
1615 | bfd_put_32 (input_bfd, x, location); | |
1616 | break; | |
1617 | case 8: | |
1618 | #ifdef BFD64 | |
1619 | bfd_put_64 (input_bfd, x, location); | |
1620 | #else | |
1621 | abort (); | |
1622 | #endif | |
1623 | break; | |
1624 | } | |
1625 | ||
1626 | return overflow ? bfd_reloc_overflow : bfd_reloc_ok; | |
1627 | } | |
2cf44d7b | 1628 | |
0cda46cf | 1629 | /* |
c26d7d17 | 1630 | DOCDD |
e98e6ec1 SC |
1631 | INODE |
1632 | howto manager, , typedef arelent, Relocations | |
1633 | ||
0cda46cf | 1634 | SECTION |
326e32d7 | 1635 | The howto manager |
2cf44d7b | 1636 | |
0cda46cf SC |
1637 | When an application wants to create a relocation, but doesn't |
1638 | know what the target machine might call it, it can find out by | |
1639 | using this bit of code. | |
2cf44d7b | 1640 | |
0cda46cf | 1641 | */ |
2cf44d7b | 1642 | |
0cda46cf SC |
1643 | /* |
1644 | TYPEDEF | |
1645 | bfd_reloc_code_type | |
2cf44d7b | 1646 | |
0cda46cf | 1647 | DESCRIPTION |
fb32909a KR |
1648 | The insides of a reloc code. The idea is that, eventually, there |
1649 | will be one enumerator for every type of relocation we ever do. | |
1650 | Pass one of these values to <<bfd_reloc_type_lookup>>, and it'll | |
1651 | return a howto pointer. | |
1652 | ||
1653 | This does mean that the application must determine the correct | |
1654 | enumerator value; you can't get a howto pointer from a random set | |
1655 | of attributes. | |
0cda46cf | 1656 | |
0443af31 KR |
1657 | SENUM |
1658 | bfd_reloc_code_real | |
1659 | ||
1660 | ENUM | |
1661 | BFD_RELOC_64 | |
1662 | ENUMX | |
1663 | BFD_RELOC_32 | |
1664 | ENUMX | |
1665 | BFD_RELOC_26 | |
1d5c6cfd DE |
1666 | ENUMX |
1667 | BFD_RELOC_24 | |
0443af31 KR |
1668 | ENUMX |
1669 | BFD_RELOC_16 | |
1670 | ENUMX | |
1671 | BFD_RELOC_14 | |
1672 | ENUMX | |
1673 | BFD_RELOC_8 | |
1674 | ENUMDOC | |
1675 | Basic absolute relocations of N bits. | |
1676 | ||
1677 | ENUM | |
1678 | BFD_RELOC_64_PCREL | |
1679 | ENUMX | |
1680 | BFD_RELOC_32_PCREL | |
1681 | ENUMX | |
1682 | BFD_RELOC_24_PCREL | |
1683 | ENUMX | |
1684 | BFD_RELOC_16_PCREL | |
fca2b81b KR |
1685 | ENUMX |
1686 | BFD_RELOC_12_PCREL | |
0443af31 KR |
1687 | ENUMX |
1688 | BFD_RELOC_8_PCREL | |
1689 | ENUMDOC | |
1690 | PC-relative relocations. Sometimes these are relative to the address | |
1691 | of the relocation itself; sometimes they are relative to the start of | |
1692 | the section containing the relocation. It depends on the specific target. | |
1693 | ||
1694 | The 24-bit relocation is used in some Intel 960 configurations. | |
1695 | ||
e9f03cd4 ILT |
1696 | ENUM |
1697 | BFD_RELOC_32_GOT_PCREL | |
1698 | ENUMX | |
1699 | BFD_RELOC_16_GOT_PCREL | |
1700 | ENUMX | |
1701 | BFD_RELOC_8_GOT_PCREL | |
1702 | ENUMX | |
1703 | BFD_RELOC_32_GOTOFF | |
1704 | ENUMX | |
1705 | BFD_RELOC_16_GOTOFF | |
1706 | ENUMX | |
1707 | BFD_RELOC_LO16_GOTOFF | |
1708 | ENUMX | |
1709 | BFD_RELOC_HI16_GOTOFF | |
1710 | ENUMX | |
1711 | BFD_RELOC_HI16_S_GOTOFF | |
1712 | ENUMX | |
1713 | BFD_RELOC_8_GOTOFF | |
1714 | ENUMX | |
1715 | BFD_RELOC_32_PLT_PCREL | |
1716 | ENUMX | |
1717 | BFD_RELOC_24_PLT_PCREL | |
1718 | ENUMX | |
1719 | BFD_RELOC_16_PLT_PCREL | |
1720 | ENUMX | |
1721 | BFD_RELOC_8_PLT_PCREL | |
1722 | ENUMX | |
1723 | BFD_RELOC_32_PLTOFF | |
1724 | ENUMX | |
1725 | BFD_RELOC_16_PLTOFF | |
1726 | ENUMX | |
1727 | BFD_RELOC_LO16_PLTOFF | |
1728 | ENUMX | |
1729 | BFD_RELOC_HI16_PLTOFF | |
1730 | ENUMX | |
1731 | BFD_RELOC_HI16_S_PLTOFF | |
1732 | ENUMX | |
1733 | BFD_RELOC_8_PLTOFF | |
1734 | ENUMDOC | |
1735 | For ELF. | |
1736 | ||
1737 | ENUM | |
1738 | BFD_RELOC_68K_GLOB_DAT | |
1739 | ENUMX | |
1740 | BFD_RELOC_68K_JMP_SLOT | |
1741 | ENUMX | |
1742 | BFD_RELOC_68K_RELATIVE | |
1743 | ENUMDOC | |
1744 | Relocations used by 68K ELF. | |
1745 | ||
0443af31 KR |
1746 | ENUM |
1747 | BFD_RELOC_32_BASEREL | |
1748 | ENUMX | |
1749 | BFD_RELOC_16_BASEREL | |
e9f03cd4 ILT |
1750 | ENUMX |
1751 | BFD_RELOC_LO16_BASEREL | |
1752 | ENUMX | |
1753 | BFD_RELOC_HI16_BASEREL | |
1754 | ENUMX | |
1755 | BFD_RELOC_HI16_S_BASEREL | |
0443af31 KR |
1756 | ENUMX |
1757 | BFD_RELOC_8_BASEREL | |
e9f03cd4 ILT |
1758 | ENUMX |
1759 | BFD_RELOC_RVA | |
0443af31 KR |
1760 | ENUMDOC |
1761 | Linkage-table relative. | |
1762 | ||
1763 | ENUM | |
1764 | BFD_RELOC_8_FFnn | |
1765 | ENUMDOC | |
1766 | Absolute 8-bit relocation, but used to form an address like 0xFFnn. | |
1767 | ||
1768 | ENUM | |
1769 | BFD_RELOC_32_PCREL_S2 | |
1770 | ENUMX | |
1771 | BFD_RELOC_16_PCREL_S2 | |
1772 | ENUMX | |
1773 | BFD_RELOC_23_PCREL_S2 | |
1774 | ENUMDOC | |
fca2b81b KR |
1775 | These PC-relative relocations are stored as word displacements -- |
1776 | i.e., byte displacements shifted right two bits. The 30-bit word | |
1777 | displacement (<<32_PCREL_S2>> -- 32 bits, shifted 2) is used on the | |
1778 | SPARC. (SPARC tools generally refer to this as <<WDISP30>>.) The | |
1779 | signed 16-bit displacement is used on the MIPS, and the 23-bit | |
1780 | displacement is used on the Alpha. | |
0443af31 KR |
1781 | |
1782 | ENUM | |
1783 | BFD_RELOC_HI22 | |
1784 | ENUMX | |
1785 | BFD_RELOC_LO10 | |
1786 | ENUMDOC | |
1787 | High 22 bits and low 10 bits of 32-bit value, placed into lower bits of | |
1788 | the target word. These are used on the SPARC. | |
1789 | ||
1790 | ENUM | |
1791 | BFD_RELOC_GPREL16 | |
1792 | ENUMX | |
1793 | BFD_RELOC_GPREL32 | |
1794 | ENUMDOC | |
1795 | For systems that allocate a Global Pointer register, these are | |
1796 | displacements off that register. These relocation types are | |
1797 | handled specially, because the value the register will have is | |
1798 | decided relatively late. | |
1799 | ||
1800 | ||
1801 | ENUM | |
1802 | BFD_RELOC_I960_CALLJ | |
1803 | ENUMDOC | |
1804 | Reloc types used for i960/b.out. | |
1805 | ||
1806 | ENUM | |
1807 | BFD_RELOC_NONE | |
1808 | ENUMX | |
1809 | BFD_RELOC_SPARC_WDISP22 | |
1810 | ENUMX | |
1811 | BFD_RELOC_SPARC22 | |
1812 | ENUMX | |
1813 | BFD_RELOC_SPARC13 | |
1814 | ENUMX | |
1815 | BFD_RELOC_SPARC_GOT10 | |
1816 | ENUMX | |
1817 | BFD_RELOC_SPARC_GOT13 | |
1818 | ENUMX | |
1819 | BFD_RELOC_SPARC_GOT22 | |
1820 | ENUMX | |
1821 | BFD_RELOC_SPARC_PC10 | |
1822 | ENUMX | |
1823 | BFD_RELOC_SPARC_PC22 | |
1824 | ENUMX | |
1825 | BFD_RELOC_SPARC_WPLT30 | |
1826 | ENUMX | |
1827 | BFD_RELOC_SPARC_COPY | |
1828 | ENUMX | |
1829 | BFD_RELOC_SPARC_GLOB_DAT | |
1830 | ENUMX | |
1831 | BFD_RELOC_SPARC_JMP_SLOT | |
1832 | ENUMX | |
1833 | BFD_RELOC_SPARC_RELATIVE | |
1834 | ENUMX | |
1835 | BFD_RELOC_SPARC_UA32 | |
1836 | ENUMDOC | |
1837 | SPARC ELF relocations. There is probably some overlap with other | |
1838 | relocation types already defined. | |
1839 | ||
1840 | ENUM | |
1841 | BFD_RELOC_SPARC_BASE13 | |
1842 | ENUMX | |
1843 | BFD_RELOC_SPARC_BASE22 | |
1844 | ENUMDOC | |
1845 | I think these are specific to SPARC a.out (e.g., Sun 4). | |
1846 | ||
1847 | ENUMEQ | |
1848 | BFD_RELOC_SPARC_64 | |
1849 | BFD_RELOC_64 | |
1850 | ENUMX | |
1851 | BFD_RELOC_SPARC_10 | |
1852 | ENUMX | |
1853 | BFD_RELOC_SPARC_11 | |
1854 | ENUMX | |
1855 | BFD_RELOC_SPARC_OLO10 | |
1856 | ENUMX | |
1857 | BFD_RELOC_SPARC_HH22 | |
1858 | ENUMX | |
1859 | BFD_RELOC_SPARC_HM10 | |
1860 | ENUMX | |
1861 | BFD_RELOC_SPARC_LM22 | |
1862 | ENUMX | |
1863 | BFD_RELOC_SPARC_PC_HH22 | |
1864 | ENUMX | |
1865 | BFD_RELOC_SPARC_PC_HM10 | |
1866 | ENUMX | |
1867 | BFD_RELOC_SPARC_PC_LM22 | |
1868 | ENUMX | |
1869 | BFD_RELOC_SPARC_WDISP16 | |
1870 | ENUMX | |
1871 | BFD_RELOC_SPARC_WDISP19 | |
1872 | ENUMX | |
1873 | BFD_RELOC_SPARC_GLOB_JMP | |
1874 | ENUMX | |
e9f03cd4 ILT |
1875 | BFD_RELOC_SPARC_7 |
1876 | ENUMX | |
1877 | BFD_RELOC_SPARC_6 | |
1878 | ENUMX | |
1879 | BFD_RELOC_SPARC_5 | |
0443af31 KR |
1880 | ENUMDOC |
1881 | Some relocations we're using for SPARC V9 -- subject to change. | |
1882 | ||
1883 | ENUM | |
1884 | BFD_RELOC_ALPHA_GPDISP_HI16 | |
1885 | ENUMDOC | |
50bd50d4 MH |
1886 | Alpha ECOFF and ELF relocations. Some of these treat the symbol or |
1887 | "addend" in some special way. | |
0443af31 KR |
1888 | For GPDISP_HI16 ("gpdisp") relocations, the symbol is ignored when |
1889 | writing; when reading, it will be the absolute section symbol. The | |
1890 | addend is the displacement in bytes of the "lda" instruction from | |
1891 | the "ldah" instruction (which is at the address of this reloc). | |
1892 | ENUM | |
1893 | BFD_RELOC_ALPHA_GPDISP_LO16 | |
1894 | ENUMDOC | |
1895 | For GPDISP_LO16 ("ignore") relocations, the symbol is handled as | |
1896 | with GPDISP_HI16 relocs. The addend is ignored when writing the | |
1897 | relocations out, and is filled in with the file's GP value on | |
1898 | reading, for convenience. | |
1899 | ||
50bd50d4 MH |
1900 | ENUM |
1901 | BFD_RELOC_ALPHA_GPDISP | |
1902 | ENUMDOC | |
1903 | The ELF GPDISP relocation is exactly the same as the GPDISP_HI16 | |
1904 | relocation except that there is no accompanying GPDISP_LO16 | |
1905 | relocation. | |
1906 | ||
0443af31 KR |
1907 | ENUM |
1908 | BFD_RELOC_ALPHA_LITERAL | |
6b31fd3a ILT |
1909 | ENUMX |
1910 | BFD_RELOC_ALPHA_ELF_LITERAL | |
0443af31 KR |
1911 | ENUMX |
1912 | BFD_RELOC_ALPHA_LITUSE | |
1913 | ENUMDOC | |
1914 | The Alpha LITERAL/LITUSE relocs are produced by a symbol reference; | |
1915 | the assembler turns it into a LDQ instruction to load the address of | |
1916 | the symbol, and then fills in a register in the real instruction. | |
1917 | ||
1918 | The LITERAL reloc, at the LDQ instruction, refers to the .lita | |
1919 | section symbol. The addend is ignored when writing, but is filled | |
1920 | in with the file's GP value on reading, for convenience, as with the | |
1921 | GPDISP_LO16 reloc. | |
1922 | ||
6b31fd3a ILT |
1923 | The ELF_LITERAL reloc is somewhere between 16_GOTOFF and GPDISP_LO16. |
1924 | It should refer to the symbol to be referenced, as with 16_GOTOFF, | |
1925 | but it generates output not based on the position within the .got | |
1926 | section, but relative to the GP value chosen for the file during the | |
1927 | final link stage. | |
1928 | ||
0443af31 KR |
1929 | The LITUSE reloc, on the instruction using the loaded address, gives |
1930 | information to the linker that it might be able to use to optimize | |
1931 | away some literal section references. The symbol is ignored (read | |
1932 | as the absolute section symbol), and the "addend" indicates the type | |
1933 | of instruction using the register: | |
1934 | 1 - "memory" fmt insn | |
1935 | 2 - byte-manipulation (byte offset reg) | |
1936 | 3 - jsr (target of branch) | |
1937 | ||
1938 | The GNU linker currently doesn't do any of this optimizing. | |
1939 | ||
1940 | ENUM | |
1941 | BFD_RELOC_ALPHA_HINT | |
1942 | ENUMDOC | |
1943 | The HINT relocation indicates a value that should be filled into the | |
1944 | "hint" field of a jmp/jsr/ret instruction, for possible branch- | |
1945 | prediction logic which may be provided on some processors. | |
1946 | ||
50bd50d4 MH |
1947 | ENUM |
1948 | BFD_RELOC_ALPHA_LINKAGE | |
1949 | ENUMDOC | |
8612a388 ILT |
1950 | The LINKAGE relocation outputs a linkage pair in the object file, |
1951 | which is filled by the linker. | |
50bd50d4 | 1952 | |
0443af31 KR |
1953 | ENUM |
1954 | BFD_RELOC_MIPS_JMP | |
1955 | ENUMDOC | |
1956 | Bits 27..2 of the relocation address shifted right 2 bits; | |
1957 | simple reloc otherwise. | |
1958 | ||
1d5c6cfd DE |
1959 | ENUM |
1960 | BFD_RELOC_MIPS16_JMP | |
1961 | ENUMDOC | |
1962 | The MIPS16 jump instruction. | |
1963 | ||
a4183ba5 ILT |
1964 | ENUM |
1965 | BFD_RELOC_MIPS16_GPREL | |
1966 | ENUMDOC | |
1967 | MIPS16 GP relative reloc. | |
1968 | ||
0443af31 KR |
1969 | ENUM |
1970 | BFD_RELOC_HI16 | |
1971 | ENUMDOC | |
1972 | High 16 bits of 32-bit value; simple reloc. | |
1973 | ENUM | |
1974 | BFD_RELOC_HI16_S | |
1975 | ENUMDOC | |
1976 | High 16 bits of 32-bit value but the low 16 bits will be sign | |
1977 | extended and added to form the final result. If the low 16 | |
1978 | bits form a negative number, we need to add one to the high value | |
1979 | to compensate for the borrow when the low bits are added. | |
1980 | ENUM | |
1981 | BFD_RELOC_LO16 | |
1982 | ENUMDOC | |
1983 | Low 16 bits. | |
1984 | ENUM | |
1985 | BFD_RELOC_PCREL_HI16_S | |
1986 | ENUMDOC | |
1987 | Like BFD_RELOC_HI16_S, but PC relative. | |
1988 | ENUM | |
1989 | BFD_RELOC_PCREL_LO16 | |
1990 | ENUMDOC | |
1991 | Like BFD_RELOC_LO16, but PC relative. | |
1992 | ||
1993 | ENUMEQ | |
1994 | BFD_RELOC_MIPS_GPREL | |
1995 | BFD_RELOC_GPREL16 | |
1996 | ENUMDOC | |
1997 | Relocation relative to the global pointer. | |
1998 | ||
1999 | ENUM | |
2000 | BFD_RELOC_MIPS_LITERAL | |
2001 | ENUMDOC | |
2002 | Relocation against a MIPS literal section. | |
2003 | ||
2004 | ENUM | |
2005 | BFD_RELOC_MIPS_GOT16 | |
2006 | ENUMX | |
2007 | BFD_RELOC_MIPS_CALL16 | |
2008 | ENUMEQX | |
2009 | BFD_RELOC_MIPS_GPREL32 | |
2010 | BFD_RELOC_GPREL32 | |
e9f03cd4 ILT |
2011 | ENUMX |
2012 | BFD_RELOC_MIPS_GOT_HI16 | |
2013 | ENUMX | |
2014 | BFD_RELOC_MIPS_GOT_LO16 | |
50bd50d4 MH |
2015 | ENUMX |
2016 | BFD_RELOC_MIPS_CALL_HI16 | |
2017 | ENUMX | |
2018 | BFD_RELOC_MIPS_CALL_LO16 | |
0443af31 KR |
2019 | ENUMDOC |
2020 | MIPS ELF relocations. | |
2021 | ||
2022 | ENUM | |
2023 | BFD_RELOC_386_GOT32 | |
2024 | ENUMX | |
2025 | BFD_RELOC_386_PLT32 | |
2026 | ENUMX | |
2027 | BFD_RELOC_386_COPY | |
2028 | ENUMX | |
2029 | BFD_RELOC_386_GLOB_DAT | |
2030 | ENUMX | |
2031 | BFD_RELOC_386_JUMP_SLOT | |
2032 | ENUMX | |
2033 | BFD_RELOC_386_RELATIVE | |
2034 | ENUMX | |
2035 | BFD_RELOC_386_GOTOFF | |
2036 | ENUMX | |
2037 | BFD_RELOC_386_GOTPC | |
2038 | ENUMDOC | |
2039 | i386/elf relocations | |
2040 | ||
2041 | ENUM | |
2042 | BFD_RELOC_NS32K_IMM_8 | |
2043 | ENUMX | |
2044 | BFD_RELOC_NS32K_IMM_16 | |
2045 | ENUMX | |
2046 | BFD_RELOC_NS32K_IMM_32 | |
2047 | ENUMX | |
2048 | BFD_RELOC_NS32K_IMM_8_PCREL | |
2049 | ENUMX | |
2050 | BFD_RELOC_NS32K_IMM_16_PCREL | |
2051 | ENUMX | |
2052 | BFD_RELOC_NS32K_IMM_32_PCREL | |
2053 | ENUMX | |
2054 | BFD_RELOC_NS32K_DISP_8 | |
2055 | ENUMX | |
2056 | BFD_RELOC_NS32K_DISP_16 | |
2057 | ENUMX | |
2058 | BFD_RELOC_NS32K_DISP_32 | |
2059 | ENUMX | |
2060 | BFD_RELOC_NS32K_DISP_8_PCREL | |
2061 | ENUMX | |
2062 | BFD_RELOC_NS32K_DISP_16_PCREL | |
2063 | ENUMX | |
2064 | BFD_RELOC_NS32K_DISP_32_PCREL | |
2065 | ENUMDOC | |
2066 | ns32k relocations | |
2067 | ||
2068 | ENUM | |
2069 | BFD_RELOC_PPC_B26 | |
e9f03cd4 | 2070 | ENUMX |
0443af31 | 2071 | BFD_RELOC_PPC_BA26 |
e9f03cd4 | 2072 | ENUMX |
0443af31 | 2073 | BFD_RELOC_PPC_TOC16 |
e9f03cd4 ILT |
2074 | ENUMX |
2075 | BFD_RELOC_PPC_B16 | |
2076 | ENUMX | |
2077 | BFD_RELOC_PPC_B16_BRTAKEN | |
2078 | ENUMX | |
2079 | BFD_RELOC_PPC_B16_BRNTAKEN | |
2080 | ENUMX | |
2081 | BFD_RELOC_PPC_BA16 | |
2082 | ENUMX | |
2083 | BFD_RELOC_PPC_BA16_BRTAKEN | |
2084 | ENUMX | |
2085 | BFD_RELOC_PPC_BA16_BRNTAKEN | |
2086 | ENUMX | |
2087 | BFD_RELOC_PPC_COPY | |
2088 | ENUMX | |
2089 | BFD_RELOC_PPC_GLOB_DAT | |
2090 | ENUMX | |
2091 | BFD_RELOC_PPC_JMP_SLOT | |
2092 | ENUMX | |
2093 | BFD_RELOC_PPC_RELATIVE | |
2094 | ENUMX | |
2095 | BFD_RELOC_PPC_LOCAL24PC | |
2096 | ENUMX | |
2097 | BFD_RELOC_PPC_EMB_NADDR32 | |
2098 | ENUMX | |
2099 | BFD_RELOC_PPC_EMB_NADDR16 | |
2100 | ENUMX | |
2101 | BFD_RELOC_PPC_EMB_NADDR16_LO | |
2102 | ENUMX | |
2103 | BFD_RELOC_PPC_EMB_NADDR16_HI | |
2104 | ENUMX | |
2105 | BFD_RELOC_PPC_EMB_NADDR16_HA | |
2106 | ENUMX | |
2107 | BFD_RELOC_PPC_EMB_SDAI16 | |
2108 | ENUMX | |
2109 | BFD_RELOC_PPC_EMB_SDA2I16 | |
2110 | ENUMX | |
2111 | BFD_RELOC_PPC_EMB_SDA2REL | |
2112 | ENUMX | |
2113 | BFD_RELOC_PPC_EMB_SDA21 | |
2114 | ENUMX | |
2115 | BFD_RELOC_PPC_EMB_MRKREF | |
2116 | ENUMX | |
2117 | BFD_RELOC_PPC_EMB_RELSEC16 | |
2118 | ENUMX | |
2119 | BFD_RELOC_PPC_EMB_RELST_LO | |
2120 | ENUMX | |
2121 | BFD_RELOC_PPC_EMB_RELST_HI | |
2122 | ENUMX | |
2123 | BFD_RELOC_PPC_EMB_RELST_HA | |
2124 | ENUMX | |
2125 | BFD_RELOC_PPC_EMB_BIT_FLD | |
2126 | ENUMX | |
2127 | BFD_RELOC_PPC_EMB_RELSDA | |
0443af31 | 2128 | ENUMDOC |
e9f03cd4 | 2129 | Power(rs6000) and PowerPC relocations. |
0443af31 KR |
2130 | |
2131 | ENUM | |
2132 | BFD_RELOC_CTOR | |
2133 | ENUMDOC | |
2134 | The type of reloc used to build a contructor table - at the moment | |
2135 | probably a 32 bit wide absolute relocation, but the target can choose. | |
2136 | It generally does map to one of the other relocation types. | |
2137 | ||
094e8be3 ILT |
2138 | ENUM |
2139 | BFD_RELOC_ARM_PCREL_BRANCH | |
2140 | ENUMDOC | |
2141 | ARM 26 bit pc-relative branch. The lowest two bits must be zero and are | |
2142 | not stored in the instruction. | |
2143 | ENUM | |
2144 | BFD_RELOC_ARM_IMMEDIATE | |
2145 | ENUMX | |
2146 | BFD_RELOC_ARM_OFFSET_IMM | |
2147 | ENUMX | |
2148 | BFD_RELOC_ARM_SHIFT_IMM | |
2149 | ENUMX | |
2150 | BFD_RELOC_ARM_SWI | |
2151 | ENUMX | |
2152 | BFD_RELOC_ARM_MULTI | |
2153 | ENUMX | |
2154 | BFD_RELOC_ARM_CP_OFF_IMM | |
e9f03cd4 ILT |
2155 | ENUMX |
2156 | BFD_RELOC_ARM_ADR_IMM | |
2157 | ENUMX | |
2158 | BFD_RELOC_ARM_LDR_IMM | |
2159 | ENUMX | |
2160 | BFD_RELOC_ARM_LITERAL | |
2161 | ENUMX | |
2162 | BFD_RELOC_ARM_IN_POOL | |
d1b40d8e JSC |
2163 | ENUMX |
2164 | BFD_RELOC_ARM_OFFSET_IMM8 | |
2165 | ENUMX | |
2166 | BFD_RELOC_ARM_HWLITERAL | |
c86158e5 ILT |
2167 | ENUMX |
2168 | BFD_RELOC_ARM_THUMB_ADD | |
2169 | ENUMX | |
2170 | BFD_RELOC_ARM_THUMB_IMM | |
2171 | ENUMX | |
2172 | BFD_RELOC_ARM_THUMB_SHIFT | |
2173 | ENUMX | |
2174 | BFD_RELOC_ARM_THUMB_OFFSET | |
094e8be3 ILT |
2175 | ENUMDOC |
2176 | These relocs are only used within the ARM assembler. They are not | |
2177 | (at present) written to any object files. | |
2178 | ||
c86158e5 ILT |
2179 | ENUM |
2180 | BFD_RELOC_SH_PCDISP8BY2 | |
2181 | ENUMX | |
2182 | BFD_RELOC_SH_PCDISP12BY2 | |
2183 | ENUMX | |
2184 | BFD_RELOC_SH_IMM4 | |
2185 | ENUMX | |
2186 | BFD_RELOC_SH_IMM4BY2 | |
2187 | ENUMX | |
2188 | BFD_RELOC_SH_IMM4BY4 | |
2189 | ENUMX | |
2190 | BFD_RELOC_SH_IMM8 | |
2191 | ENUMX | |
2192 | BFD_RELOC_SH_IMM8BY2 | |
2193 | ENUMX | |
2194 | BFD_RELOC_SH_IMM8BY4 | |
2195 | ENUMX | |
2196 | BFD_RELOC_SH_PCRELIMM8BY2 | |
2197 | ENUMX | |
2198 | BFD_RELOC_SH_PCRELIMM8BY4 | |
2199 | ENUMX | |
2200 | BFD_RELOC_SH_SWITCH16 | |
2201 | ENUMX | |
2202 | BFD_RELOC_SH_SWITCH32 | |
2203 | ENUMX | |
2204 | BFD_RELOC_SH_USES | |
2205 | ENUMX | |
2206 | BFD_RELOC_SH_COUNT | |
2207 | ENUMX | |
2208 | BFD_RELOC_SH_ALIGN | |
2209 | ENUMX | |
2210 | BFD_RELOC_SH_CODE | |
2211 | ENUMX | |
2212 | BFD_RELOC_SH_DATA | |
2213 | ENUMX | |
2214 | BFD_RELOC_SH_LABEL | |
2215 | ENUMDOC | |
2216 | Hitachi SH relocs. Not all of these appear in object files. | |
2217 | ||
82b1edf7 KR |
2218 | COMMENT |
2219 | {* start-sanitize-arc *} | |
2220 | ENUM | |
2221 | BFD_RELOC_ARC_B22_PCREL | |
2222 | ENUMDOC | |
2223 | Argonaut RISC Core (ARC) relocs. | |
2224 | ARC 22 bit pc-relative branch. The lowest two bits must be zero and are | |
e9f03cd4 ILT |
2225 | not stored in the instruction. The high 20 bits are installed in bits 26 |
2226 | through 7 of the instruction. | |
2227 | ENUM | |
2228 | BFD_RELOC_ARC_B26 | |
2229 | ENUMDOC | |
2230 | ARC 26 bit absolute branch. The lowest two bits must be zero and are not | |
2231 | stored in the instruction. The high 24 bits are installed in bits 23 | |
2232 | through 0. | |
82b1edf7 KR |
2233 | COMMENT |
2234 | {* end-sanitize-arc *} | |
50bd50d4 MH |
2235 | |
2236 | COMMENT | |
2237 | {* start-sanitize-d10v *} | |
2238 | ENUM | |
2239 | BFD_RELOC_D10V_10_PCREL_R | |
2240 | ENUMDOC | |
2241 | Mitsubishi D10V relocs. | |
2242 | This is a 10-bit reloc with the right 2 bits | |
2243 | assumed to be 0. | |
2244 | ENUM | |
2245 | BFD_RELOC_D10V_10_PCREL_L | |
2246 | ENUMDOC | |
2247 | Mitsubishi D10V relocs. | |
2248 | This is a 10-bit reloc with the right 2 bits | |
2249 | assumed to be 0. This is the same as the previous reloc | |
2250 | except it is in the left container, i.e., | |
2251 | shifted left 15 bits. | |
2252 | ENUM | |
2253 | BFD_RELOC_D10V_18 | |
2254 | ENUMDOC | |
2255 | This is an 18-bit reloc with the right 2 bits | |
2256 | assumed to be 0. | |
2257 | ENUM | |
2258 | BFD_RELOC_D10V_18_PCREL | |
2259 | ENUMDOC | |
2260 | This is an 18-bit reloc with the right 2 bits | |
2261 | assumed to be 0. | |
2262 | COMMENT | |
2263 | {* end-sanitize-d10v *} | |
2264 | ||
a5a43df1 ILT |
2265 | COMMENT |
2266 | {* start-sanitize-m32r *} | |
2267 | ENUM | |
1d5c6cfd | 2268 | BFD_RELOC_M32R_24 |
a5a43df1 ILT |
2269 | ENUMDOC |
2270 | Mitsubishi M32R relocs. | |
1d5c6cfd | 2271 | This is a 24 bit absolute address. |
6b31fd3a | 2272 | ENUM |
1d5c6cfd | 2273 | BFD_RELOC_M32R_10_PCREL |
6b31fd3a | 2274 | ENUMDOC |
1d5c6cfd | 2275 | This is a 10-bit pc-relative reloc with the right 2 bits assumed to be 0. |
a5a43df1 | 2276 | ENUM |
1d5c6cfd | 2277 | BFD_RELOC_M32R_18_PCREL |
a5a43df1 ILT |
2278 | ENUMDOC |
2279 | This is an 18-bit reloc with the right 2 bits assumed to be 0. | |
2280 | ENUM | |
1d5c6cfd DE |
2281 | BFD_RELOC_M32R_26_PCREL |
2282 | ENUMDOC | |
2283 | This is a 26-bit reloc with the right 2 bits assumed to be 0. | |
2284 | ENUM | |
2285 | BFD_RELOC_M32R_HI16_ULO | |
2286 | ENUMDOC | |
2287 | This is a 16-bit reloc containing the high 16 bits of an address | |
2288 | used when the lower 16 bits are treated as unsigned. | |
2289 | ENUM | |
2290 | BFD_RELOC_M32R_HI16_SLO | |
2291 | ENUMDOC | |
2292 | This is a 16-bit reloc containing the high 16 bits of an address | |
2293 | used when the lower 16 bits are treated as signed. | |
2294 | ENUM | |
2295 | BFD_RELOC_M32R_LO16 | |
a5a43df1 | 2296 | ENUMDOC |
1d5c6cfd | 2297 | This is a 16-bit reloc containing the lower 16 bits of an address. |
a5a43df1 ILT |
2298 | COMMENT |
2299 | {* end-sanitize-m32r *} | |
2300 | ||
2301 | COMMENT | |
2302 | {* start-sanitize-v850 *} | |
2303 | ENUM | |
2304 | BFD_RELOC_V850_9_PCREL | |
2305 | ENUMDOC | |
2306 | This is a 9-bit reloc | |
2307 | ENUM | |
2308 | BFD_RELOC_V850_22_PCREL | |
2309 | ENUMDOC | |
2310 | This is a 22-bit reloc | |
b6d08fce JL |
2311 | ENUM |
2312 | BFD_RELOC_V850_SDA_OFFSET | |
2313 | ENUMDOC | |
2314 | This is an offset from the short data area pointer.. | |
2315 | ENUM | |
2316 | BFD_RELOC_V850_ZDA_OFFSET | |
2317 | ENUMDOC | |
2318 | This is an offset from the zero data area pointer.. | |
2319 | ENUM | |
2320 | BFD_RELOC_V850_TDA_OFFSET | |
2321 | ENUMDOC | |
2322 | This is an offset from the tiny data area pointer.. | |
a5a43df1 ILT |
2323 | COMMENT |
2324 | {* end-sanitize-v850 *} | |
2325 | ||
1d5c6cfd DE |
2326 | ENUM |
2327 | BFD_RELOC_MN10300_32_PCREL | |
2328 | ENUMDOC | |
2329 | This is a 32bit pcrel reloc for the mn10300, offset by two bytes in the | |
2330 | instruction. | |
2331 | ENUM | |
2332 | BFD_RELOC_MN10300_16_PCREL | |
2333 | ENUMDOC | |
2334 | This is a 16bit pcrel reloc for the mn10300, offset by two bytes in the | |
2335 | instruction. | |
0443af31 KR |
2336 | ENDSENUM |
2337 | BFD_RELOC_UNUSED | |
e98e6ec1 SC |
2338 | CODE_FRAGMENT |
2339 | . | |
0443af31 | 2340 | .typedef enum bfd_reloc_code_real bfd_reloc_code_real_type; |
2cf44d7b SC |
2341 | */ |
2342 | ||
2343 | ||
0cda46cf | 2344 | /* |
c188b0be | 2345 | FUNCTION |
0cda46cf | 2346 | bfd_reloc_type_lookup |
2cf44d7b | 2347 | |
e98e6ec1 | 2348 | SYNOPSIS |
e9f03cd4 | 2349 | reloc_howto_type * |
3860075f | 2350 | bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code); |
e98e6ec1 | 2351 | |
0cda46cf | 2352 | DESCRIPTION |
4c3721d5 | 2353 | Return a pointer to a howto structure which, when |
c188b0be | 2354 | invoked, will perform the relocation @var{code} on data from the |
0cda46cf | 2355 | architecture noted. |
2cf44d7b | 2356 | |
2cf44d7b SC |
2357 | */ |
2358 | ||
2359 | ||
e9f03cd4 | 2360 | reloc_howto_type * |
326e32d7 ILT |
2361 | bfd_reloc_type_lookup (abfd, code) |
2362 | bfd *abfd; | |
2363 | bfd_reloc_code_real_type code; | |
2cf44d7b | 2364 | { |
8070f29d | 2365 | return BFD_SEND (abfd, reloc_type_lookup, (abfd, code)); |
2cf44d7b SC |
2366 | } |
2367 | ||
0cda46cf | 2368 | static reloc_howto_type bfd_howto_32 = |
326e32d7 | 2369 | HOWTO (0, 00, 2, 32, false, 0, complain_overflow_bitfield, 0, "VRT32", false, 0xffffffff, 0xffffffff, true); |
2cf44d7b SC |
2370 | |
2371 | ||
0cda46cf | 2372 | /* |
e98e6ec1 | 2373 | INTERNAL_FUNCTION |
0cda46cf SC |
2374 | bfd_default_reloc_type_lookup |
2375 | ||
0cda46cf | 2376 | SYNOPSIS |
e9f03cd4 | 2377 | reloc_howto_type *bfd_default_reloc_type_lookup |
326e32d7 | 2378 | (bfd *abfd, bfd_reloc_code_real_type code); |
0cda46cf | 2379 | |
e98e6ec1 | 2380 | DESCRIPTION |
65cab589 | 2381 | Provides a default relocation lookup routine for any architecture. |
e98e6ec1 SC |
2382 | |
2383 | ||
0cda46cf | 2384 | */ |
65cab589 | 2385 | |
e9f03cd4 | 2386 | reloc_howto_type * |
326e32d7 ILT |
2387 | bfd_default_reloc_type_lookup (abfd, code) |
2388 | bfd *abfd; | |
2389 | bfd_reloc_code_real_type code; | |
0cda46cf | 2390 | { |
326e32d7 | 2391 | switch (code) |
0cda46cf | 2392 | { |
65cab589 DM |
2393 | case BFD_RELOC_CTOR: |
2394 | /* The type of reloc used in a ctor, which will be as wide as the | |
fb32909a | 2395 | address - so either a 64, 32, or 16 bitter. */ |
326e32d7 ILT |
2396 | switch (bfd_get_arch_info (abfd)->bits_per_address) |
2397 | { | |
2398 | case 64: | |
2399 | BFD_FAIL (); | |
2400 | case 32: | |
2401 | return &bfd_howto_32; | |
2402 | case 16: | |
2403 | BFD_FAIL (); | |
2404 | default: | |
2405 | BFD_FAIL (); | |
2406 | } | |
65cab589 | 2407 | default: |
326e32d7 | 2408 | BFD_FAIL (); |
0cda46cf | 2409 | } |
e9f03cd4 | 2410 | return (reloc_howto_type *) NULL; |
0cda46cf | 2411 | } |
e98e6ec1 | 2412 | |
0443af31 KR |
2413 | /* |
2414 | FUNCTION | |
2415 | bfd_get_reloc_code_name | |
2416 | ||
2417 | SYNOPSIS | |
2418 | const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code); | |
2419 | ||
2420 | DESCRIPTION | |
2421 | Provides a printable name for the supplied relocation code. | |
2422 | Useful mainly for printing error messages. | |
2423 | */ | |
2424 | ||
2425 | const char * | |
2426 | bfd_get_reloc_code_name (code) | |
2427 | bfd_reloc_code_real_type code; | |
2428 | { | |
2429 | if (code > BFD_RELOC_UNUSED) | |
2430 | return 0; | |
2431 | return bfd_reloc_code_real_names[(int)code]; | |
2432 | } | |
e98e6ec1 | 2433 | |
d58b7049 SC |
2434 | /* |
2435 | INTERNAL_FUNCTION | |
2436 | bfd_generic_relax_section | |
2437 | ||
2438 | SYNOPSIS | |
2439 | boolean bfd_generic_relax_section | |
2440 | (bfd *abfd, | |
2441 | asection *section, | |
4c3721d5 | 2442 | struct bfd_link_info *, |
326e32d7 | 2443 | boolean *); |
d58b7049 SC |
2444 | |
2445 | DESCRIPTION | |
2446 | Provides default handling for relaxing for back ends which | |
8070f29d | 2447 | don't do relaxing -- i.e., does nothing. |
d58b7049 SC |
2448 | */ |
2449 | ||
563eb766 | 2450 | /*ARGSUSED*/ |
d58b7049 | 2451 | boolean |
326e32d7 | 2452 | bfd_generic_relax_section (abfd, section, link_info, again) |
4c3721d5 ILT |
2453 | bfd *abfd; |
2454 | asection *section; | |
2455 | struct bfd_link_info *link_info; | |
326e32d7 | 2456 | boolean *again; |
d58b7049 | 2457 | { |
326e32d7 ILT |
2458 | *again = false; |
2459 | return true; | |
d58b7049 | 2460 | } |
326e32d7 | 2461 | |
e98e6ec1 SC |
2462 | /* |
2463 | INTERNAL_FUNCTION | |
2464 | bfd_generic_get_relocated_section_contents | |
2465 | ||
2466 | SYNOPSIS | |
2467 | bfd_byte * | |
65cab589 | 2468 | bfd_generic_get_relocated_section_contents (bfd *abfd, |
4c3721d5 ILT |
2469 | struct bfd_link_info *link_info, |
2470 | struct bfd_link_order *link_order, | |
65cab589 | 2471 | bfd_byte *data, |
4c3721d5 ILT |
2472 | boolean relocateable, |
2473 | asymbol **symbols); | |
e98e6ec1 SC |
2474 | |
2475 | DESCRIPTION | |
2476 | Provides default handling of relocation effort for back ends | |
2477 | which can't be bothered to do it efficiently. | |
2478 | ||
2479 | */ | |
2480 | ||
2481 | bfd_byte * | |
4c3721d5 ILT |
2482 | bfd_generic_get_relocated_section_contents (abfd, link_info, link_order, data, |
2483 | relocateable, symbols) | |
2484 | bfd *abfd; | |
2485 | struct bfd_link_info *link_info; | |
2486 | struct bfd_link_order *link_order; | |
2487 | bfd_byte *data; | |
2488 | boolean relocateable; | |
2489 | asymbol **symbols; | |
e98e6ec1 | 2490 | { |
e98e6ec1 | 2491 | /* Get enough memory to hold the stuff */ |
4c3721d5 ILT |
2492 | bfd *input_bfd = link_order->u.indirect.section->owner; |
2493 | asection *input_section = link_order->u.indirect.section; | |
e98e6ec1 | 2494 | |
326e32d7 | 2495 | long reloc_size = bfd_get_reloc_upper_bound (input_bfd, input_section); |
80425e6c | 2496 | arelent **reloc_vector = NULL; |
326e32d7 ILT |
2497 | long reloc_count; |
2498 | ||
2499 | if (reloc_size < 0) | |
2500 | goto error_return; | |
80425e6c | 2501 | |
e9f03cd4 | 2502 | reloc_vector = (arelent **) bfd_malloc ((size_t) reloc_size); |
326e32d7 | 2503 | if (reloc_vector == NULL && reloc_size != 0) |
e9f03cd4 | 2504 | goto error_return; |
326e32d7 | 2505 | |
e98e6ec1 | 2506 | /* read in the section */ |
326e32d7 ILT |
2507 | if (!bfd_get_section_contents (input_bfd, |
2508 | input_section, | |
2509 | (PTR) data, | |
2510 | 0, | |
2511 | input_section->_raw_size)) | |
80425e6c JK |
2512 | goto error_return; |
2513 | ||
2514 | /* We're not relaxing the section, so just copy the size info */ | |
e98e6ec1 SC |
2515 | input_section->_cooked_size = input_section->_raw_size; |
2516 | input_section->reloc_done = true; | |
e98e6ec1 | 2517 | |
326e32d7 ILT |
2518 | reloc_count = bfd_canonicalize_reloc (input_bfd, |
2519 | input_section, | |
2520 | reloc_vector, | |
2521 | symbols); | |
2522 | if (reloc_count < 0) | |
80425e6c JK |
2523 | goto error_return; |
2524 | ||
326e32d7 ILT |
2525 | if (reloc_count > 0) |
2526 | { | |
2527 | arelent **parent; | |
2528 | for (parent = reloc_vector; *parent != (arelent *) NULL; | |
2529 | parent++) | |
65cab589 | 2530 | { |
326e32d7 ILT |
2531 | char *error_message = (char *) NULL; |
2532 | bfd_reloc_status_type r = | |
2533 | bfd_perform_relocation (input_bfd, | |
2534 | *parent, | |
2535 | (PTR) data, | |
2536 | input_section, | |
2537 | relocateable ? abfd : (bfd *) NULL, | |
2538 | &error_message); | |
2539 | ||
2540 | if (relocateable) | |
2541 | { | |
2542 | asection *os = input_section->output_section; | |
65cab589 | 2543 | |
326e32d7 ILT |
2544 | /* A partial link, so keep the relocs */ |
2545 | os->orelocation[os->reloc_count] = *parent; | |
2546 | os->reloc_count++; | |
2547 | } | |
e98e6ec1 | 2548 | |
326e32d7 ILT |
2549 | if (r != bfd_reloc_ok) |
2550 | { | |
2551 | switch (r) | |
2552 | { | |
2553 | case bfd_reloc_undefined: | |
2554 | if (!((*link_info->callbacks->undefined_symbol) | |
2555 | (link_info, bfd_asymbol_name (*(*parent)->sym_ptr_ptr), | |
2556 | input_bfd, input_section, (*parent)->address))) | |
2557 | goto error_return; | |
2558 | break; | |
2559 | case bfd_reloc_dangerous: | |
2560 | BFD_ASSERT (error_message != (char *) NULL); | |
2561 | if (!((*link_info->callbacks->reloc_dangerous) | |
2562 | (link_info, error_message, input_bfd, input_section, | |
2563 | (*parent)->address))) | |
2564 | goto error_return; | |
2565 | break; | |
2566 | case bfd_reloc_overflow: | |
2567 | if (!((*link_info->callbacks->reloc_overflow) | |
2568 | (link_info, bfd_asymbol_name (*(*parent)->sym_ptr_ptr), | |
2569 | (*parent)->howto->name, (*parent)->addend, | |
2570 | input_bfd, input_section, (*parent)->address))) | |
2571 | goto error_return; | |
2572 | break; | |
2573 | case bfd_reloc_outofrange: | |
2574 | default: | |
2575 | abort (); | |
2576 | break; | |
2577 | } | |
e98e6ec1 | 2578 | |
326e32d7 ILT |
2579 | } |
2580 | } | |
2581 | } | |
80425e6c JK |
2582 | if (reloc_vector != NULL) |
2583 | free (reloc_vector); | |
e98e6ec1 SC |
2584 | return data; |
2585 | ||
326e32d7 | 2586 | error_return: |
80425e6c JK |
2587 | if (reloc_vector != NULL) |
2588 | free (reloc_vector); | |
2589 | return NULL; | |
e98e6ec1 | 2590 | } |