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