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