Commit | Line | Data |
---|---|---|
c618de01 SC |
1 | /* BFD support for handling relocation entries. |
2 | Copyright (C) 1990-1991 Free Software Foundation, Inc. | |
3 | Written by Cygnus Support. | |
4 | ||
5 | This file is part of BFD, the Binary File Descriptor library. | |
6 | ||
7 | This program is free software; you can redistribute it and/or modify | |
8 | it under the terms of the GNU General Public License as published by | |
9 | the Free Software Foundation; either version 2 of the License, or | |
10 | (at your option) any later version. | |
11 | ||
12 | This program is distributed in the hope that it will be useful, | |
13 | but WITHOUT ANY WARRANTY; without even the implied warranty of | |
14 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
15 | GNU General Public License for more details. | |
16 | ||
17 | You should have received a copy of the GNU General Public License | |
18 | along with this program; if not, write to the Free Software | |
19 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ | |
20 | ||
0cda46cf SC |
21 | /* |
22 | SECTION | |
23 | Relocations | |
985fca12 | 24 | |
0cda46cf SC |
25 | DESCRIPTION |
26 | BFD maintains relocations in much the same was as it maintains | |
27 | symbols; they are left alone until required, then read in | |
28 | en-mass and traslated into an internal form. There is a common | |
29 | routine <<bfd_perform_relocation>> which acts upon the | |
30 | canonical form to to the actual fixup. | |
985fca12 | 31 | |
0cda46cf SC |
32 | Note that relocations are maintained on a per section basis, |
33 | whilst symbols are maintained on a per BFD basis. | |
985fca12 | 34 | |
0cda46cf SC |
35 | All a back end has to do to fit the BFD interface is to create |
36 | as many <<struct reloc_cache_entry>> as there are relocations | |
37 | in a particuar section, and fill in the right bits: | |
985fca12 SC |
38 | |
39 | @menu | |
40 | * typedef arelent:: | |
0cda46cf | 41 | * howto manager:: |
985fca12 SC |
42 | @end menu |
43 | ||
44 | */ | |
985fca12 | 45 | #include "bfd.h" |
0cda46cf | 46 | #include "sysdep.h" |
985fca12 | 47 | #include "libbfd.h" |
0cda46cf SC |
48 | /*doc* |
49 | @node typedef arelent, howto manager, Relocations, Relocations | |
985fca12 | 50 | |
0cda46cf SC |
51 | SUBSECTION |
52 | typedef arelent | |
985fca12 SC |
53 | |
54 | */ | |
55 | ||
0cda46cf SC |
56 | /* |
57 | FUNCTION | |
58 | bfd_perform_relocation | |
985fca12 | 59 | |
0cda46cf SC |
60 | DESCRIPTION |
61 | The relocation routine returns as a status an enumerated type: | |
985fca12 | 62 | |
0cda46cf SC |
63 | .typedef enum bfd_reloc_status { |
64 | No errors detected | |
985fca12 | 65 | |
0cda46cf | 66 | . bfd_reloc_ok, |
985fca12 | 67 | |
0cda46cf | 68 | The relocation was performed, but there was an overflow. |
985fca12 | 69 | |
0cda46cf | 70 | . bfd_reloc_overflow, |
985fca12 | 71 | |
0cda46cf | 72 | The address to relocate was not within the section supplied |
985fca12 | 73 | |
0cda46cf | 74 | . bfd_reloc_outofrange, |
985fca12 | 75 | |
0cda46cf | 76 | Used by special functions |
985fca12 | 77 | |
0cda46cf | 78 | . bfd_reloc_continue, |
985fca12 | 79 | |
0cda46cf | 80 | Unused |
985fca12 | 81 | |
0cda46cf | 82 | . bfd_reloc_notsupported, |
985fca12 | 83 | |
0cda46cf | 84 | Unsupported relocation size requested. |
985fca12 | 85 | |
0cda46cf | 86 | . bfd_reloc_other, |
985fca12 | 87 | |
0cda46cf | 88 | The symbol to relocate against was undefined. |
985fca12 | 89 | |
0cda46cf | 90 | . bfd_reloc_undefined, |
985fca12 | 91 | |
0cda46cf SC |
92 | The relocation was performed, but may not be ok - presently |
93 | generated only when linking i960 coff files with i960 b.out symbols. | |
985fca12 | 94 | |
0cda46cf SC |
95 | . bfd_reloc_dangerous |
96 | . } | |
97 | . bfd_reloc_status_type; | |
985fca12 | 98 | |
985fca12 | 99 | |
0cda46cf SC |
100 | .typedef struct reloc_cache_entry |
101 | .{ | |
985fca12 | 102 | |
0cda46cf | 103 | A pointer into the canonical table of pointers |
985fca12 | 104 | |
0cda46cf | 105 | . struct symbol_cache_entry **sym_ptr_ptr; |
985fca12 | 106 | |
0cda46cf | 107 | offset in section |
985fca12 | 108 | |
0cda46cf | 109 | . rawdata_offset address; |
985fca12 | 110 | |
0cda46cf | 111 | addend for relocation value |
985fca12 | 112 | |
0cda46cf | 113 | . bfd_vma addend; |
985fca12 | 114 | |
0cda46cf | 115 | if sym is null this is the section |
985fca12 | 116 | |
0cda46cf | 117 | . struct sec *section; |
985fca12 | 118 | |
0cda46cf | 119 | Pointer to how to perform the required relocation |
985fca12 | 120 | |
0cda46cf SC |
121 | . CONST struct reloc_howto_struct *howto; |
122 | .} arelent; | |
985fca12 | 123 | |
985fca12 SC |
124 | |
125 | */ | |
126 | ||
0cda46cf SC |
127 | /* |
128 | DESCRIPTION | |
129 | ||
130 | o sym_ptr_ptr | |
131 | The symbol table pointer points to a pointer to the symbol | |
132 | associated with the relocation request. This would naturally | |
133 | be the pointer into the table returned by the back end's | |
134 | get_symtab action. @xref{Symbols}. The symbol is referenced | |
135 | through a pointer to a pointer so that tools like the linker | |
136 | can fix up all the symbols of the same name by modifying only | |
137 | one pointer. The relocation routine looks in the symbol and | |
138 | uses the base of the section the symbol is attached to and the | |
139 | value of the symbol as the initial relocation offset. If the | |
140 | symbol pointer is zero, then the section provided is looked up. | |
141 | ||
142 | o address | |
143 | The address field gives the offset in bytes from the base of | |
144 | the section data which owns the relocation record to the first | |
145 | byte of relocatable information. The actual data relocated | |
146 | will be relative to this point - for example, a relocation | |
147 | type which modifies the bottom two bytes of a four byte word | |
148 | would not touch the first byte pointed to in a big endian | |
149 | world. @item addend The addend is a value provided by the back | |
150 | end to be added (!) to the relocation offset. Its | |
151 | interpretation is dependent upon the howto. For example, on | |
152 | the 68k the code: | |
153 | ||
154 | EXAMPLE | |
155 | ||
985fca12 SC |
156 | char foo[]; |
157 | main() | |
158 | { | |
159 | return foo[0x12345678]; | |
160 | } | |
985fca12 | 161 | |
0cda46cf SC |
162 | DESCRIPTION |
163 | Could be compiled into: | |
164 | ||
165 | EXAMPLE | |
985fca12 SC |
166 | linkw fp,#-4 |
167 | moveb @@#12345678,d0 | |
168 | extbl d0 | |
169 | unlk fp | |
170 | rts | |
985fca12 | 171 | |
0cda46cf SC |
172 | DESCRIPTION |
173 | ||
174 | This could create a reloc pointing to foo, but leave the | |
175 | offset in the data (something like) | |
985fca12 | 176 | |
0cda46cf | 177 | EXAMPLE |
985fca12 | 178 | RELOCATION RECORDS FOR [.text]: |
0cda46cf | 179 | offset type value |
985fca12 SC |
180 | 00000006 32 _foo |
181 | ||
182 | 00000000 4e56 fffc ; linkw fp,#-4 | |
183 | 00000004 1039 1234 5678 ; moveb @@#12345678,d0 | |
184 | 0000000a 49c0 ; extbl d0 | |
185 | 0000000c 4e5e ; unlk fp | |
186 | 0000000e 4e75 ; rts | |
0cda46cf | 187 | DESCRIPTION |
985fca12 | 188 | |
0cda46cf SC |
189 | Using coff and an 88k, some instructions don't have enough |
190 | space in them to represent the full address range, and | |
191 | pointers have to be loaded in two parts. So you'd get something like: | |
192 | ||
193 | EXAMPLE | |
985fca12 SC |
194 | or.u r13,r0,hi16(_foo+0x12345678) |
195 | ld.b r2,r13,lo16(_foo+0x12345678) | |
196 | jmp r1 | |
985fca12 | 197 | |
0cda46cf SC |
198 | DESCRIPTION |
199 | This whould create two relocs, both pointing to _foo, and with | |
200 | 0x12340000 in their addend field. The data would consist of: | |
985fca12 | 201 | |
0cda46cf | 202 | EXAMPLE |
985fca12 | 203 | RELOCATION RECORDS FOR [.text]: |
0cda46cf | 204 | offset type value |
985fca12 SC |
205 | 00000002 HVRT16 _foo+0x12340000 |
206 | 00000006 LVRT16 _foo+0x12340000 | |
207 | ||
208 | 00000000 5da05678 ; or.u r13,r0,0x5678 | |
209 | 00000004 1c4d5678 ; ld.b r2,r13,0x5678 | |
210 | 00000008 f400c001 ; jmp r1 | |
0cda46cf SC |
211 | |
212 | DESCRIPTION | |
213 | The relocation routine digs out the value from the data, adds | |
214 | it to the addend to get the original offset and then adds the | |
215 | value of _foo. Note that all 32 bits have to be kept around | |
216 | somewhere, to cope with carry from bit 15 to bit 16. | |
217 | ||
218 | On further example is the sparc and the a.out format. The | |
219 | sparc has a similar problem to the 88k, in that some | |
220 | instructions don't have room for an entire offset, but on the | |
221 | sparc the parts are created odd sized lumps. The designers of | |
222 | the a.out format chose not to use the data within the section | |
223 | for storing part of the offset; all the offset is kept within | |
224 | the reloc. Any thing in the data should be ignored. | |
225 | EXAMPLE | |
985fca12 SC |
226 | save %sp,-112,%sp |
227 | sethi %hi(_foo+0x12345678),%g2 | |
228 | ldsb [%g2+%lo(_foo+0x12345678)],%i0 | |
229 | ret | |
230 | restore | |
985fca12 | 231 | |
0cda46cf SC |
232 | DESCRIPTION |
233 | Both relocs contains a pointer to foo, and the offsets would | |
234 | contain junk. | |
235 | ||
236 | EXAMPLE | |
237 | ||
985fca12 | 238 | RELOCATION RECORDS FOR [.text]: |
0cda46cf | 239 | offset type value |
985fca12 SC |
240 | 00000004 HI22 _foo+0x12345678 |
241 | 00000008 LO10 _foo+0x12345678 | |
242 | ||
243 | 00000000 9de3bf90 ; save %sp,-112,%sp | |
244 | 00000004 05000000 ; sethi %hi(_foo+0),%g2 | |
245 | 00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0 | |
246 | 0000000c 81c7e008 ; ret | |
247 | 00000010 81e80000 ; restore | |
0cda46cf SC |
248 | |
249 | DESCRIPTION | |
250 | ||
251 | o section | |
252 | The section field is only used when the symbol pointer field | |
253 | is null. It supplies the section into which the data should be | |
254 | relocated. The field's main use comes from assemblers which do | |
255 | most of the symbol fixups themselves; an assembler may take an | |
256 | internal reference to a label, but since it knows where the | |
257 | label is, it can turn the relocation request from a symbol | |
258 | lookup into a section relative relocation - the relocation | |
259 | emitted has no symbol, just a section to relocate against. I'm | |
260 | not sure what it means when both a symbol pointer an a section | |
261 | pointer are present. Some formats use this sort of mechanism | |
262 | to describe PIC relocations, but BFD can't to that sort of | |
263 | thing yet. @item howto The howto field can be imagined as a | |
264 | relocation instruction. It is a pointer to a struct which | |
265 | contains information on what to do with all the other | |
266 | information in the reloc record and data section. A back end | |
267 | would normally have a relocation instruction set and turn | |
268 | relocations into pointers to the correct structure on input - | |
269 | but it would be possible to create each howto field on demand. | |
270 | ||
985fca12 SC |
271 | */ |
272 | ||
273 | ||
0cda46cf SC |
274 | /* |
275 | SUBSUBSECTION | |
276 | <<reloc_howto_type>> | |
985fca12 | 277 | |
0cda46cf SC |
278 | DESCRIPTION |
279 | The <<reloc_howto_type>> is a structure which contains all the | |
280 | information that BFD needs to know to tie up a back end's data. | |
985fca12 | 281 | |
0cda46cf SC |
282 | .typedef CONST struct reloc_howto_struct |
283 | .{ | |
284 | The type field has mainly a documetary use - the back end can | |
285 | to what it wants with it, though the normally the back end's | |
286 | external idea of what a reloc number would be would be stored | |
287 | in this field. For example, the a PC relative word relocation | |
288 | in a coff environment would have the type 023 - because that's | |
289 | what the outside world calls a R_PCRWORD reloc. | |
985fca12 | 290 | |
0cda46cf | 291 | . unsigned int type; |
985fca12 | 292 | |
0cda46cf SC |
293 | The value the final relocation is shifted right by. This drops |
294 | unwanted data from the relocation. | |
985fca12 | 295 | |
0cda46cf | 296 | . unsigned int rightshift; |
985fca12 | 297 | |
0cda46cf SC |
298 | The size of the item to be relocated - 0, is one byte, 1 is 2 |
299 | bytes, 3 is four bytes. | |
985fca12 | 300 | |
0cda46cf | 301 | . unsigned int size; |
985fca12 | 302 | |
0cda46cf | 303 | Now obsolete |
985fca12 | 304 | |
0cda46cf | 305 | . unsigned int bitsize; |
985fca12 | 306 | |
0cda46cf SC |
307 | Notes that the relocation is relative to the location in the |
308 | data section of the addend. The relocation function will | |
309 | subtract from the relocation value the address of the location | |
310 | being relocated. | |
985fca12 | 311 | |
0cda46cf | 312 | . boolean pc_relative; |
985fca12 | 313 | |
0cda46cf | 314 | Now obsolete |
985fca12 | 315 | |
0cda46cf | 316 | . unsigned int bitpos; |
985fca12 | 317 | |
0cda46cf | 318 | Now obsolete |
985fca12 | 319 | |
0cda46cf | 320 | . boolean absolute; |
985fca12 | 321 | |
0cda46cf SC |
322 | Causes the relocation routine to return an error if overflow |
323 | is detected when relocating. | |
985fca12 | 324 | |
0cda46cf | 325 | . boolean complain_on_overflow; |
985fca12 | 326 | |
0cda46cf SC |
327 | If this field is non null, then the supplied function is |
328 | called rather than the normal function. This allows really | |
329 | strange relocation methods to be accomodated (eg, i960 callj | |
330 | instructions). | |
985fca12 | 331 | |
0cda46cf | 332 | . bfd_reloc_status_type (*special_function)(); |
985fca12 | 333 | |
0cda46cf | 334 | The textual name of the relocation type. |
985fca12 | 335 | |
0cda46cf | 336 | . char *name; |
985fca12 | 337 | |
0cda46cf SC |
338 | When performing a partial link, some formats must modify the |
339 | relocations rather than the data - this flag signals this. | |
985fca12 | 340 | |
0cda46cf | 341 | . boolean partial_inplace; |
985fca12 | 342 | |
0cda46cf SC |
343 | The src_mask is used to select what parts of the read in data |
344 | are to be used in the relocation sum. Eg, if this was an 8 bit | |
345 | bit of data which we read and relocated, this would be | |
346 | 0x000000ff. When we have relocs which have an addend, such as | |
347 | sun4 extended relocs, the value in the offset part of a | |
348 | relocating field is garbage so we never use it. In this case | |
349 | the mask would be 0x00000000. | |
350 | . bfd_word src_mask; | |
985fca12 | 351 | |
0cda46cf SC |
352 | The dst_mask is what parts of the instruction are replaced |
353 | into the instruction. In most cases src_mask == dst_mask, | |
354 | except in the above special case, where dst_mask would be | |
355 | 0x000000ff, and src_mask would be 0x00000000. | |
356 | . bfd_word dst_mask; | |
985fca12 | 357 | |
0cda46cf SC |
358 | When some formats create PC relative instructions, they leave |
359 | the value of the pc of the place being relocated in the offset | |
360 | slot of the instruction, so that a PC relative relocation can | |
361 | be made just by adding in an ordinary offset (eg sun3 a.out). | |
362 | Some formats leave the displacement part of an instruction | |
363 | empty (eg m88k bcs), this flag signals the fact. | |
364 | . boolean pcrel_offset; | |
365 | .} reloc_howto_type; | |
985fca12 | 366 | |
0cda46cf | 367 | */ |
985fca12 | 368 | |
0cda46cf SC |
369 | /* |
370 | FUNCTION | |
371 | HOWTO | |
372 | DESCRIPTION | |
373 | The HOWTO define is horrible and will go away. | |
374 | ||
375 | ||
376 | .#define HOWTO(C, R,S,B, P, BI, ABS, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \ | |
377 | . {(unsigned)C,R,S,B, P, BI, ABS,O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC} | |
378 | ||
379 | DESCRIPTION | |
380 | And will be replaced with the totally magic way. But for the | |
381 | moment, we are compatible, so do it this way.. | |
382 | ||
383 | ||
384 | .#define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,false,false,FUNCTION, NAME,false,0,0,IN) | |
385 | . | |
386 | DESCRIPTION | |
387 | Helper routine to turn a symbol into a relocation value. | |
388 | ||
389 | .#define HOWTO_PREPARE(relocation, symbol) \ | |
390 | . { \ | |
391 | . if (symbol != (asymbol *)NULL) { \ | |
392 | . if (symbol->flags & BSF_FORT_COMM) { \ | |
393 | . relocation = 0; \ | |
394 | . } \ | |
395 | . else { \ | |
396 | . relocation = symbol->value; \ | |
397 | . } \ | |
398 | . } \ | |
399 | . if (symbol->section != (asection *)NULL) { \ | |
400 | . relocation += symbol->section->output_section->vma + \ | |
401 | . symbol->section->output_offset; \ | |
402 | . } \ | |
403 | .} | |
985fca12 SC |
404 | |
405 | */ | |
406 | ||
0cda46cf SC |
407 | /* |
408 | TYPEDEF | |
409 | reloc_chain | |
985fca12 | 410 | |
0cda46cf | 411 | DESCRIPTION |
985fca12 | 412 | |
0cda46cf | 413 | How relocs are tied together |
985fca12 | 414 | |
0cda46cf SC |
415 | .typedef unsigned char bfd_byte; |
416 | . | |
417 | .typedef struct relent_chain { | |
418 | . arelent relent; | |
419 | . struct relent_chain *next; | |
420 | .} arelent_chain; | |
985fca12 SC |
421 | |
422 | */ | |
423 | ||
424 | ||
425 | ||
0cda46cf SC |
426 | /* |
427 | FUNCTION | |
428 | bfd_perform_relocation | |
429 | ||
430 | DESCRIPTION | |
431 | If an output_bfd is supplied to this function the generated | |
432 | image will be relocatable, the relocations are copied to the | |
433 | output file after they have been changed to reflect the new | |
434 | state of the world. There are two ways of reflecting the | |
435 | results of partial linkage in an output file; by modifying the | |
436 | output data in place, and by modifying the relocation record. | |
437 | Some native formats (eg basic a.out and basic coff) have no | |
438 | way of specifying an addend in the relocation type, so the | |
439 | addend has to go in the output data. This is no big deal | |
440 | since in these formats the output data slot will always be big | |
441 | enough for the addend. Complex reloc types with addends were | |
442 | invented to solve just this problem. | |
443 | ||
444 | SYNOPSIS | |
445 | bfd_reloc_status_type | |
446 | bfd_perform_relocation | |
985fca12 SC |
447 | (bfd * abfd, |
448 | arelent *reloc_entry, | |
449 | PTR data, | |
450 | asection *input_section, | |
0cda46cf | 451 | bfd *output_bfd); |
985fca12 SC |
452 | */ |
453 | ||
454 | ||
0cda46cf | 455 | bfd_reloc_status_type |
985fca12 SC |
456 | DEFUN(bfd_perform_relocation,(abfd, |
457 | reloc_entry, | |
458 | data, | |
459 | input_section, | |
460 | output_bfd), | |
461 | bfd *abfd AND | |
462 | arelent *reloc_entry AND | |
463 | PTR data AND | |
464 | asection *input_section AND | |
465 | bfd *output_bfd) | |
466 | { | |
467 | bfd_vma relocation; | |
0cda46cf | 468 | bfd_reloc_status_type flag = bfd_reloc_ok; |
985fca12 SC |
469 | bfd_vma addr = reloc_entry->address ; |
470 | bfd_vma output_base = 0; | |
471 | reloc_howto_type *howto = reloc_entry->howto; | |
472 | asection *reloc_target_output_section; | |
473 | asection *reloc_target_input_section; | |
474 | asymbol *symbol; | |
475 | ||
476 | if (reloc_entry->sym_ptr_ptr) { | |
477 | symbol = *( reloc_entry->sym_ptr_ptr); | |
478 | if ((symbol->flags & BSF_UNDEFINED) && output_bfd == (bfd *)NULL) { | |
479 | flag = bfd_reloc_undefined; | |
480 | } | |
481 | } | |
482 | else { | |
483 | symbol = (asymbol*)NULL; | |
484 | } | |
485 | ||
486 | if (howto->special_function){ | |
0cda46cf | 487 | bfd_reloc_status_type cont; |
985fca12 SC |
488 | cont = howto->special_function(abfd, |
489 | reloc_entry, | |
490 | symbol, | |
491 | data, | |
492 | input_section); | |
493 | if (cont != bfd_reloc_continue) return cont; | |
494 | } | |
495 | ||
496 | /* | |
497 | Work out which section the relocation is targetted at and the | |
498 | initial relocation command value. | |
499 | */ | |
500 | ||
501 | ||
502 | if (symbol != (asymbol *)NULL){ | |
503 | if (symbol->flags & BSF_FORT_COMM) { | |
504 | relocation = 0; | |
505 | } | |
506 | else { | |
507 | relocation = symbol->value; | |
508 | } | |
509 | if (symbol->section != (asection *)NULL) | |
510 | { | |
511 | reloc_target_input_section = symbol->section; | |
512 | } | |
513 | else { | |
514 | reloc_target_input_section = (asection *)NULL; | |
515 | } | |
516 | } | |
517 | else if (reloc_entry->section != (asection *)NULL) | |
518 | { | |
519 | relocation = 0; | |
520 | reloc_target_input_section = reloc_entry->section; | |
521 | } | |
522 | else { | |
523 | relocation = 0; | |
524 | reloc_target_input_section = (asection *)NULL; | |
525 | } | |
526 | ||
527 | ||
528 | if (reloc_target_input_section != (asection *)NULL) { | |
529 | ||
530 | reloc_target_output_section = | |
531 | reloc_target_input_section->output_section; | |
532 | ||
533 | if (output_bfd && howto->partial_inplace==false) { | |
534 | output_base = 0; | |
535 | } | |
536 | else { | |
537 | output_base = reloc_target_output_section->vma; | |
538 | ||
539 | } | |
540 | ||
541 | relocation += output_base + reloc_target_input_section->output_offset; | |
542 | } | |
543 | ||
544 | relocation += reloc_entry->addend ; | |
545 | ||
546 | ||
547 | if(reloc_entry->address > (bfd_vma)(input_section->size)) | |
548 | { | |
549 | return bfd_reloc_outofrange; | |
550 | } | |
551 | ||
552 | ||
553 | if (howto->pc_relative == true) | |
554 | { | |
555 | /* | |
556 | Anything which started out as pc relative should end up that | |
c618de01 SC |
557 | way too. |
558 | ||
559 | There are two ways we can see a pcrel instruction. Sometimes | |
560 | the pcrel displacement has been partially calculated, it | |
561 | includes the distance from the start of the section to the | |
562 | instruction in it (eg sun3), and sometimes the field is | |
563 | totally blank - eg m88kbcs. | |
564 | */ | |
985fca12 SC |
565 | |
566 | ||
567 | relocation -= | |
d0a27c3b | 568 | input_section->output_section->vma + input_section->output_offset; |
985fca12 SC |
569 | |
570 | if (howto->pcrel_offset == true) { | |
571 | relocation -= reloc_entry->address; | |
572 | } | |
573 | ||
574 | } | |
575 | ||
576 | if (output_bfd!= (bfd *)NULL) { | |
577 | if ( howto->partial_inplace == false) { | |
578 | /* | |
579 | This is a partial relocation, and we want to apply the relocation | |
c618de01 SC |
580 | to the reloc entry rather than the raw data. Modify the reloc |
581 | inplace to reflect what we now know. | |
582 | */ | |
985fca12 SC |
583 | reloc_entry->addend = relocation ; |
584 | reloc_entry->section = reloc_target_input_section; | |
585 | if (reloc_target_input_section != (asection *)NULL) { | |
586 | /* If we know the output section we can forget the symbol */ | |
587 | reloc_entry->sym_ptr_ptr = (asymbol**)NULL; | |
588 | } | |
589 | reloc_entry->address += | |
590 | input_section->output_offset; | |
591 | return flag; | |
592 | } | |
593 | else | |
594 | { | |
595 | /* This is a partial relocation, but inplace, so modify the | |
c618de01 SC |
596 | reloc record a bit. |
597 | ||
598 | If we've relocated with a symbol with a section, change | |
599 | into a ref to the section belonging to the symbol | |
600 | */ | |
601 | ||
602 | if (symbol != (asymbol *)NULL && reloc_target_input_section != (asection *)NULL) | |
603 | { | |
604 | reloc_entry->section = reloc_target_input_section; | |
605 | reloc_entry->sym_ptr_ptr = (asymbol **)NULL; | |
606 | } | |
985fca12 SC |
607 | |
608 | } | |
609 | } | |
610 | ||
611 | reloc_entry->addend = 0; | |
612 | ||
613 | ||
614 | /* | |
615 | Either we are relocating all the way, or we don't want to apply | |
616 | the relocation to the reloc entry (probably because there isn't | |
617 | any room in the output format to describe addends to relocs) | |
618 | */ | |
619 | relocation >>= howto->rightshift; | |
620 | ||
621 | /* Shift everything up to where it's going to be used */ | |
622 | ||
623 | relocation <<= howto->bitpos; | |
624 | ||
625 | /* Wait for the day when all have the mask in them */ | |
626 | ||
627 | /* What we do: | |
628 | i instruction to be left alone | |
629 | o offset within instruction | |
630 | r relocation offset to apply | |
631 | S src mask | |
632 | D dst mask | |
633 | N ~dst mask | |
634 | A part 1 | |
635 | B part 2 | |
636 | R result | |
637 | ||
638 | Do this: | |
639 | i i i i i o o o o o from bfd_get<size> | |
640 | and S S S S S to get the size offset we want | |
641 | + r r r r r r r r r r to get the final value to place | |
642 | and D D D D D to chop to right size | |
643 | ----------------------- | |
644 | A A A A A | |
645 | And this: | |
646 | ... i i i i i o o o o o from bfd_get<size> | |
647 | and N N N N N get instruction | |
648 | ----------------------- | |
649 | ... B B B B B | |
650 | ||
651 | And then: | |
652 | B B B B B | |
653 | or A A A A A | |
654 | ----------------------- | |
655 | R R R R R R R R R R put into bfd_put<size> | |
656 | */ | |
657 | ||
658 | #define DOIT(x) \ | |
659 | x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask)) | |
660 | ||
661 | switch (howto->size) | |
662 | { | |
663 | case 0: | |
664 | { | |
665 | char x = bfd_get_8(abfd, (char *)data + addr); | |
666 | DOIT(x); | |
667 | bfd_put_8(abfd,x, (unsigned char *) data + addr); | |
668 | } | |
669 | break; | |
670 | ||
671 | case 1: | |
672 | { | |
673 | short x = bfd_get_16(abfd, (bfd_byte *)data + addr); | |
674 | DOIT(x); | |
675 | bfd_put_16(abfd, x, (unsigned char *)data + addr); | |
676 | } | |
677 | break; | |
678 | case 2: | |
679 | { | |
680 | long x = bfd_get_32(abfd, (bfd_byte *) data + addr); | |
681 | DOIT(x); | |
682 | bfd_put_32(abfd,x, (bfd_byte *)data + addr); | |
683 | } | |
684 | break; | |
685 | case 3: | |
c618de01 | 686 | |
985fca12 SC |
687 | /* Do nothing */ |
688 | break; | |
689 | default: | |
690 | return bfd_reloc_other; | |
691 | } | |
692 | ||
693 | return flag; | |
694 | } | |
c618de01 SC |
695 | |
696 | ||
2cf44d7b | 697 | |
0cda46cf SC |
698 | /* |
699 | @node howto manager, , typedef arelent, Relocations | |
700 | SECTION | |
701 | The howto manager | |
2cf44d7b | 702 | |
0cda46cf SC |
703 | DESCRIPTION |
704 | When an application wants to create a relocation, but doesn't | |
705 | know what the target machine might call it, it can find out by | |
706 | using this bit of code. | |
2cf44d7b | 707 | |
0cda46cf | 708 | */ |
2cf44d7b | 709 | |
0cda46cf SC |
710 | /* |
711 | TYPEDEF | |
712 | bfd_reloc_code_type | |
2cf44d7b | 713 | |
0cda46cf SC |
714 | DESCRIPTION |
715 | The insides of a reloc code | |
716 | ||
717 | .typedef enum bfd_reloc_code_real { | |
718 | ||
719 | 16 bits wide, simple reloc | |
2cf44d7b | 720 | |
0cda46cf | 721 | . BFD_RELOC_16, |
2cf44d7b | 722 | |
0cda46cf | 723 | 8 bits wide, but used to form an address like 0xffnn |
2cf44d7b | 724 | |
0cda46cf | 725 | . BFD_RELOC_8_FFnn, |
2cf44d7b | 726 | |
0cda46cf | 727 | 8 bits wide, simple |
2cf44d7b | 728 | |
0cda46cf | 729 | . BFD_RELOC_8, |
2cf44d7b | 730 | |
0cda46cf | 731 | 8 bits wide, pc relative |
2cf44d7b | 732 | |
0cda46cf | 733 | . BFD_RELOC_8_PCREL, |
2cf44d7b | 734 | |
0cda46cf SC |
735 | The type of reloc used to build a contructor table - at the |
736 | moment probably a 32 bit wide abs address, but the cpu can | |
737 | choose. | |
2cf44d7b | 738 | |
0cda46cf | 739 | . BFD_RELOC_CTOR |
2cf44d7b | 740 | |
0cda46cf | 741 | . } bfd_reloc_code_real_type; |
2cf44d7b | 742 | |
2cf44d7b | 743 | |
2cf44d7b SC |
744 | |
745 | */ | |
746 | ||
747 | ||
748 | ||
0cda46cf SC |
749 | /* |
750 | SECTION | |
751 | bfd_reloc_type_lookup | |
2cf44d7b | 752 | |
0cda46cf SC |
753 | DESCRIPTION |
754 | This routine returns a pointer to a howto struct which when | |
755 | invoked, will perform the supplied relocation on data from the | |
756 | architecture noted. | |
2cf44d7b | 757 | |
0cda46cf SC |
758 | SYNOPSIS |
759 | CONST struct reloc_howto_struct * | |
760 | bfd_reloc_type_lookup | |
761 | (CONST bfd_arch_info_type *arch, bfd_reloc_code_type code); | |
2cf44d7b SC |
762 | */ |
763 | ||
764 | ||
765 | CONST struct reloc_howto_struct * | |
766 | DEFUN(bfd_reloc_type_lookup,(arch, code), | |
0cda46cf SC |
767 | CONST bfd_arch_info_type *arch AND |
768 | bfd_reloc_code_type code) | |
2cf44d7b SC |
769 | { |
770 | return arch->reloc_type_lookup(arch, code); | |
771 | } | |
772 | ||
0cda46cf SC |
773 | static reloc_howto_type bfd_howto_32 = |
774 | HOWTO(0, 00,2,32,false,0,false,true,0,"VRT32", false,0xffffffff,0xffffffff,true); | |
2cf44d7b SC |
775 | |
776 | ||
0cda46cf SC |
777 | /* |
778 | INTERNAL FUNCTION | |
779 | bfd_default_reloc_type_lookup | |
780 | ||
781 | DESCRIPTION | |
782 | Provides a default relocation lookuperer for any architectue | |
783 | ||
784 | SYNOPSIS | |
785 | CONST struct reloc_howto_struct *bfd_default_reloc_type_lookup | |
786 | (CONST struct bfd_arch_info *, | |
787 | bfd_reloc_code_type code); | |
788 | ||
789 | */ | |
790 | CONST struct reloc_howto_struct * | |
791 | DEFUN(bfd_default_reloc_type_lookup,(arch, code), | |
792 | CONST struct bfd_arch_info *arch AND | |
793 | bfd_reloc_code_type code) | |
794 | { | |
795 | switch (code) | |
796 | { | |
797 | case BFD_RELOC_CTOR: | |
798 | /* The type of reloc used in a ctor, which will be as wide as the | |
799 | address - so either a 64, 32, or 16 bitter.. */ | |
800 | switch (arch->bits_per_address) { | |
801 | case 64: | |
802 | BFD_FAIL(); | |
803 | case 32: | |
804 | return &bfd_howto_32; | |
805 | case 16: | |
806 | BFD_FAIL(); | |
807 | default: | |
808 | BFD_FAIL(); | |
809 | } | |
810 | default: | |
811 | BFD_FAIL(); | |
812 | } | |
813 | return (struct reloc_howto_struct *)NULL; | |
814 | } |