1 /* BFD support for handling relocation entries.
2 Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
3 Written by Cygnus Support.
5 This file is part of BFD, the Binary File Descriptor library.
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.
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.
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. */
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.
31 Relocations are maintained on a per section basis,
32 while symbols are maintained on a per BFD basis.
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.
45 /* DO compile in the reloc_code name table from libbfd.h. */
46 #define _BFD_MAKE_TABLE_bfd_reloc_code_real
55 typedef arelent, howto manager, Relocations, Relocations
60 This is the structure of a relocation entry:
64 .typedef enum bfd_reloc_status
66 . {* No errors detected *}
69 . {* The relocation was performed, but there was an overflow. *}
72 . {* The address to relocate was not within the section supplied. *}
73 . bfd_reloc_outofrange,
75 . {* Used by special functions *}
78 . {* Unsupported relocation size requested. *}
79 . bfd_reloc_notsupported,
84 . {* The symbol to relocate against was undefined. *}
85 . bfd_reloc_undefined,
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. *}
93 . bfd_reloc_status_type;
96 .typedef struct reloc_cache_entry
98 . {* A pointer into the canonical table of pointers *}
99 . struct symbol_cache_entry **sym_ptr_ptr;
101 . {* offset in section *}
102 . bfd_size_type address;
104 . {* addend for relocation value *}
107 . {* Pointer to how to perform the required relocation *}
108 . const struct reloc_howto_struct *howto;
117 Here is a description of each of the fields within an <<arelent>>:
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.
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
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:
152 | return foo[0x12345678];
155 Could be compiled into:
158 | moveb @@#12345678,d0
164 This could create a reloc pointing to <<foo>>, but leave the
165 offset in the data, something like:
168 |RELOCATION RECORDS FOR [.text]:
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
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:
184 | or.u r13,r0,hi16(_foo+0x12345678)
185 | ld.b r2,r13,lo16(_foo+0x12345678)
189 This should create two relocs, both pointing to <<_foo>>, and with
190 0x12340000 in their addend field. The data would consist of:
193 |RELOCATION RECORDS FOR [.text]:
195 |00000002 HVRT16 _foo+0x12340000
196 |00000006 LVRT16 _foo+0x12340000
198 |00000000 5da05678 ; or.u r13,r0,0x5678
199 |00000004 1c4d5678 ; ld.b r2,r13,0x5678
200 |00000008 f400c001 ; jmp r1
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.
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.
217 | sethi %hi(_foo+0x12345678),%g2
218 | ldsb [%g2+%lo(_foo+0x12345678)],%i0
222 Both relocs contain a pointer to <<foo>>, and the offsets
226 |RELOCATION RECORDS FOR [.text]:
228 |00000004 HI22 _foo+0x12345678
229 |00000008 LO10 _foo+0x12345678
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
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.
252 <<enum complain_overflow>>
254 Indicates what sort of overflow checking should be done when
255 performing a relocation.
259 .enum complain_overflow
261 . {* Do not complain on overflow. *}
262 . complain_overflow_dont,
264 . {* Complain if the bitfield overflows, whether it is considered
265 . as signed or unsigned. *}
266 . complain_overflow_bitfield,
268 . {* Complain if the value overflows when considered as signed
270 . complain_overflow_signed,
272 . {* Complain if the value overflows when considered as an
273 . unsigned number. *}
274 . complain_overflow_unsigned
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.
287 .struct symbol_cache_entry; {* Forward declaration *}
289 .typedef unsigned char bfd_byte;
290 .typedef struct reloc_howto_struct reloc_howto_type;
292 .struct reloc_howto_struct
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. *}
302 . {* The value the final relocation is shifted right by. This drops
303 . unwanted data from the relocation. *}
304 . unsigned int rightshift;
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. *}
311 . {* The number of bits in the item to be relocated. This is used
312 . when doing overflow checking. *}
313 . unsigned int bitsize;
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;
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;
325 . {* What type of overflow error should be checked for when
327 . enum complain_overflow complain_on_overflow;
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
333 . bfd_reloc_status_type (*special_function)
334 . PARAMS ((bfd *abfd,
335 . arelent *reloc_entry,
336 . struct symbol_cache_entry *symbol,
338 . asection *input_section,
340 . char **error_message));
342 . {* The textual name of the relocation type. *}
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;
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. *}
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. *}
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;
381 The HOWTO define is horrible and will go away.
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}
388 And will be replaced with the totally magic way. But for the
389 moment, we are compatible, so do it this way.
392 .#define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,complain_overflow_dont,FUNCTION, NAME,false,0,0,IN)
395 Helper routine to turn a symbol into a relocation value.
397 .#define HOWTO_PREPARE(relocation, symbol) \
399 . if (symbol != (asymbol *)NULL) { \
400 . if (bfd_is_com_section (symbol->section)) { \
404 . relocation = symbol->value; \
416 int bfd_get_reloc_size (const reloc_howto_type *);
419 For a reloc_howto_type that operates on a fixed number of bytes,
420 this returns the number of bytes operated on.
424 bfd_get_reloc_size (howto
)
425 const reloc_howto_type
*howto
;
445 How relocs are tied together in an <<asection>>:
447 .typedef struct relent_chain {
449 . struct relent_chain *next;
458 bfd_perform_relocation
461 bfd_reloc_status_type
462 bfd_perform_relocation
464 arelent *reloc_entry,
466 asection *input_section,
468 char **error_message);
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}.
489 bfd_reloc_status_type
490 bfd_perform_relocation (abfd
, reloc_entry
, data
, input_section
, output_bfd
,
493 arelent
*reloc_entry
;
495 asection
*input_section
;
497 char **error_message
;
500 bfd_reloc_status_type flag
= bfd_reloc_ok
;
501 bfd_size_type addr
= reloc_entry
->address
;
502 bfd_vma output_base
= 0;
503 const reloc_howto_type
*howto
= reloc_entry
->howto
;
504 asection
*reloc_target_output_section
;
507 symbol
= *(reloc_entry
->sym_ptr_ptr
);
508 if (bfd_is_abs_section (symbol
->section
)
509 && output_bfd
!= (bfd
*) NULL
)
511 reloc_entry
->address
+= input_section
->output_offset
;
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
;
523 /* If there is a function supplied to handle this relocation type,
524 call it. It'll return `bfd_reloc_continue' if further processing
526 if (howto
->special_function
)
528 bfd_reloc_status_type cont
;
529 cont
= howto
->special_function (abfd
, reloc_entry
, symbol
, data
,
530 input_section
, output_bfd
,
532 if (cont
!= bfd_reloc_continue
)
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
;
540 /* Work out which section the relocation is targetted at and the
541 initial relocation command value. */
543 /* Get symbol value. (Common symbols are special.) */
544 if (bfd_is_com_section (symbol
->section
))
547 relocation
= symbol
->value
;
550 reloc_target_output_section
= symbol
->section
->output_section
;
552 /* Convert input-section-relative symbol value to absolute. */
553 if (output_bfd
&& howto
->partial_inplace
== false)
556 output_base
= reloc_target_output_section
->vma
;
558 relocation
+= output_base
+ symbol
->section
->output_offset
;
560 /* Add in supplied addend. */
561 relocation
+= reloc_entry
->addend
;
563 /* Here the variable relocation holds the final address of the
564 symbol we are relocating against, plus any addend. */
566 if (howto
->pc_relative
== true)
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.
572 We start by subtracting the address of the section containing
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.
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.
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. */
597 input_section
->output_section
->vma
+ input_section
->output_offset
;
599 if (howto
->pcrel_offset
== true)
600 relocation
-= reloc_entry
->address
;
603 if (output_bfd
!= (bfd
*) NULL
)
605 if (howto
->partial_inplace
== false)
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
;
616 /* This is a partial relocation, but inplace, so modify the
619 If we've relocated with a symbol with a section, change
620 into a ref to the section belonging to the symbol. */
622 reloc_entry
->address
+= input_section
->output_offset
;
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)
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.
635 However, Ian wrote the following, regarding removing the line below,
636 which explains why it is still enabled: --djm
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.
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.
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.
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).
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).
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.
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:
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
695 6) if the resulting object files are the same, you have at least
697 7) if they are different you have to figure out which version is
700 relocation
-= reloc_entry
->addend
;
702 reloc_entry
->addend
= 0;
706 reloc_entry
->addend
= relocation
;
712 reloc_entry
->addend
= 0;
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
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
)
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
);
731 check
= relocation
<< (howto
->bitpos
- howto
->rightshift
);
732 switch (howto
->complain_on_overflow
)
734 case complain_overflow_signed
:
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
;
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
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
;
752 case complain_overflow_unsigned
:
754 /* Assumes two's complement. This expression avoids
755 overflow if howto->bitsize is the number of bits in
757 bfd_vma reloc_unsigned_max
=
758 (((1 << (howto
->bitsize
- 1)) - 1) << 1) | 1;
760 if ((bfd_vma
) check
> reloc_unsigned_max
)
761 flag
= bfd_reloc_overflow
;
764 case complain_overflow_bitfield
:
766 /* Assumes two's complement. This expression avoids
767 overflow if howto->bitsize is the number of bits in
769 bfd_vma reloc_bits
= (((1 << (howto
->bitsize
- 1)) - 1) << 1) | 1;
771 if (((bfd_vma
) check
& ~reloc_bits
) != 0
772 && ((bfd_vma
) check
& ~reloc_bits
) != (-1 & ~reloc_bits
))
774 /* The above right shift is incorrect for a signed
775 value. See if turning on the upper bits fixes the
777 if (howto
->rightshift
> howto
->bitpos
778 && (bfd_signed_vma
) relocation
< 0)
780 check
|= ((bfd_vma
) - 1
782 >> (howto
->rightshift
- howto
->bitpos
)));
783 if (((bfd_vma
) check
& ~reloc_bits
) != (-1 & ~reloc_bits
))
784 flag
= bfd_reloc_overflow
;
787 flag
= bfd_reloc_overflow
;
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)
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
817 x <<= (unsigned long) s.i0;
821 printf ("succeeded (%lx)\n", x);
825 relocation
>>= (bfd_vma
) howto
->rightshift
;
827 /* Shift everything up to where it's going to be used */
829 relocation
<<= (bfd_vma
) howto
->bitpos
;
831 /* Wait for the day when all have the mask in them */
834 i instruction to be left alone
835 o offset within instruction
836 r relocation offset to apply
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 -----------------------
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 -----------------------
860 -----------------------
861 R R R R R R R R R R put into bfd_put<size>
865 x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask))
871 char x
= bfd_get_8 (abfd
, (char *) data
+ addr
);
873 bfd_put_8 (abfd
, x
, (unsigned char *) data
+ addr
);
880 short x
= bfd_get_16 (abfd
, (bfd_byte
*) data
+ addr
);
882 bfd_put_16 (abfd
, x
, (unsigned char *) data
+ addr
);
888 long x
= bfd_get_32 (abfd
, (bfd_byte
*) data
+ addr
);
890 bfd_put_32 (abfd
, x
, (bfd_byte
*) data
+ addr
);
895 long x
= bfd_get_32 (abfd
, (bfd_byte
*) data
+ addr
);
896 relocation
= -relocation
;
898 bfd_put_32 (abfd
, x
, (bfd_byte
*) data
+ addr
);
910 bfd_vma x
= bfd_get_64 (abfd
, (bfd_byte
*) data
+ addr
);
912 bfd_put_64 (abfd
, x
, (bfd_byte
*) data
+ addr
);
919 return bfd_reloc_other
;
925 /* This relocation routine is used by some of the backend linkers.
926 They do not construct asymbol or arelent structures, so there is no
927 reason for them to use bfd_perform_relocation. Also,
928 bfd_perform_relocation is so hacked up it is easier to write a new
929 function than to try to deal with it.
931 This routine does a final relocation. It should not be used when
932 generating relocateable output.
934 FIXME: This routine ignores any special_function in the HOWTO,
935 since the existing special_function values have been written for
936 bfd_perform_relocation.
938 HOWTO is the reloc howto information.
939 INPUT_BFD is the BFD which the reloc applies to.
940 INPUT_SECTION is the section which the reloc applies to.
941 CONTENTS is the contents of the section.
942 ADDRESS is the address of the reloc within INPUT_SECTION.
943 VALUE is the value of the symbol the reloc refers to.
944 ADDEND is the addend of the reloc. */
946 bfd_reloc_status_type
947 _bfd_final_link_relocate (howto
, input_bfd
, input_section
, contents
, address
,
949 const reloc_howto_type
*howto
;
951 asection
*input_section
;
959 /* Sanity check the address. */
960 if (address
> input_section
->_cooked_size
)
961 return bfd_reloc_outofrange
;
963 /* This function assumes that we are dealing with a basic relocation
964 against a symbol. We want to compute the value of the symbol to
965 relocate to. This is just VALUE, the value of the symbol, plus
966 ADDEND, any addend associated with the reloc. */
967 relocation
= value
+ addend
;
969 /* If the relocation is PC relative, we want to set RELOCATION to
970 the distance between the symbol (currently in RELOCATION) and the
971 location we are relocating. Some targets (e.g., i386-aout)
972 arrange for the contents of the section to be the negative of the
973 offset of the location within the section; for such targets
974 pcrel_offset is false. Other targets (e.g., m88kbcs or ELF)
975 simply leave the contents of the section as zero; for such
976 targets pcrel_offset is true. If pcrel_offset is false we do not
977 need to subtract out the offset of the location within the
978 section (which is just ADDRESS). */
979 if (howto
->pc_relative
)
981 relocation
-= (input_section
->output_section
->vma
982 + input_section
->output_offset
);
983 if (howto
->pcrel_offset
)
984 relocation
-= address
;
987 return _bfd_relocate_contents (howto
, input_bfd
, relocation
,
991 /* Relocate a given location using a given value and howto. */
993 bfd_reloc_status_type
994 _bfd_relocate_contents (howto
, input_bfd
, relocation
, location
)
995 const reloc_howto_type
*howto
;
1004 /* If the size is negative, negate RELOCATION. This isn't very
1006 if (howto
->size
< 0)
1007 relocation
= -relocation
;
1009 /* Get the value we are going to relocate. */
1010 size
= bfd_get_reloc_size (howto
);
1017 x
= bfd_get_8 (input_bfd
, location
);
1020 x
= bfd_get_16 (input_bfd
, location
);
1023 x
= bfd_get_32 (input_bfd
, location
);
1027 x
= bfd_get_64 (input_bfd
, location
);
1034 /* Check for overflow. FIXME: We may drop bits during the addition
1035 which we don't check for. We must either check at every single
1036 operation, which would be tedious, or we must do the computations
1037 in a type larger than bfd_vma, which would be inefficient. */
1039 if (howto
->complain_on_overflow
!= complain_overflow_dont
)
1042 bfd_signed_vma signed_check
;
1044 bfd_signed_vma signed_add
;
1046 if (howto
->rightshift
== 0)
1049 signed_check
= (bfd_signed_vma
) relocation
;
1053 /* Drop unwanted bits from the value we are relocating to. */
1054 check
= relocation
>> howto
->rightshift
;
1056 /* If this is a signed value, the rightshift just dropped
1057 leading 1 bits (assuming twos complement). */
1058 if ((bfd_signed_vma
) relocation
>= 0)
1059 signed_check
= check
;
1061 signed_check
= (check
1063 & ~((bfd_vma
) - 1 >> howto
->rightshift
)));
1066 /* Get the value from the object file. */
1067 add
= x
& howto
->src_mask
;
1069 /* Get the value from the object file with an appropriate sign.
1070 The expression involving howto->src_mask isolates the upper
1071 bit of src_mask. If that bit is set in the value we are
1072 adding, it is negative, and we subtract out that number times
1073 two. If src_mask includes the highest possible bit, then we
1074 can not get the upper bit, but that does not matter since
1075 signed_add needs no adjustment to become negative in that
1078 if ((add
& (((~howto
->src_mask
) >> 1) & howto
->src_mask
)) != 0)
1079 signed_add
-= (((~howto
->src_mask
) >> 1) & howto
->src_mask
) << 1;
1081 /* Add the value from the object file, shifted so that it is a
1083 if (howto
->bitpos
== 0)
1086 signed_check
+= signed_add
;
1090 check
+= add
>> howto
->bitpos
;
1092 /* For the signed case we use ADD, rather than SIGNED_ADD,
1093 to avoid warnings from SVR4 cc. This is OK since we
1094 explictly handle the sign bits. */
1095 if (signed_add
>= 0)
1096 signed_check
+= add
>> howto
->bitpos
;
1098 signed_check
+= ((add
>> howto
->bitpos
)
1100 & ~((bfd_vma
) - 1 >> howto
->bitpos
)));
1103 switch (howto
->complain_on_overflow
)
1105 case complain_overflow_signed
:
1107 /* Assumes two's complement. */
1108 bfd_signed_vma reloc_signed_max
= (1 << (howto
->bitsize
- 1)) - 1;
1109 bfd_signed_vma reloc_signed_min
= ~reloc_signed_max
;
1111 if (signed_check
> reloc_signed_max
1112 || signed_check
< reloc_signed_min
)
1116 case complain_overflow_unsigned
:
1118 /* Assumes two's complement. This expression avoids
1119 overflow if howto->bitsize is the number of bits in
1121 bfd_vma reloc_unsigned_max
=
1122 (((1 << (howto
->bitsize
- 1)) - 1) << 1) | 1;
1124 if (check
> reloc_unsigned_max
)
1128 case complain_overflow_bitfield
:
1130 /* Assumes two's complement. This expression avoids
1131 overflow if howto->bitsize is the number of bits in
1133 bfd_vma reloc_bits
= (((1 << (howto
->bitsize
- 1)) - 1) << 1) | 1;
1135 if ((check
& ~reloc_bits
) != 0
1136 && (((bfd_vma
) signed_check
& ~reloc_bits
)
1137 != (-1 & ~reloc_bits
)))
1146 /* Put RELOCATION in the right bits. */
1147 relocation
>>= (bfd_vma
) howto
->rightshift
;
1148 relocation
<<= (bfd_vma
) howto
->bitpos
;
1150 /* Add RELOCATION to the right bits of X. */
1151 x
= ((x
& ~howto
->dst_mask
)
1152 | (((x
& howto
->src_mask
) + relocation
) & howto
->dst_mask
));
1154 /* Put the relocated value back in the object file. */
1161 bfd_put_8 (input_bfd
, x
, location
);
1164 bfd_put_16 (input_bfd
, x
, location
);
1167 bfd_put_32 (input_bfd
, x
, location
);
1171 bfd_put_64 (input_bfd
, x
, location
);
1178 return overflow
? bfd_reloc_overflow
: bfd_reloc_ok
;
1184 howto manager, , typedef arelent, Relocations
1189 When an application wants to create a relocation, but doesn't
1190 know what the target machine might call it, it can find out by
1191 using this bit of code.
1200 The insides of a reloc code. The idea is that, eventually, there
1201 will be one enumerator for every type of relocation we ever do.
1202 Pass one of these values to <<bfd_reloc_type_lookup>>, and it'll
1203 return a howto pointer.
1205 This does mean that the application must determine the correct
1206 enumerator value; you can't get a howto pointer from a random set
1225 Basic absolute relocations of N bits.
1238 PC-relative relocations. Sometimes these are relative to the address
1239 of the relocation itself; sometimes they are relative to the start of
1240 the section containing the relocation. It depends on the specific target.
1242 The 24-bit relocation is used in some Intel 960 configurations.
1245 BFD_RELOC_32_BASEREL
1247 BFD_RELOC_16_BASEREL
1251 Linkage-table relative.
1256 Absolute 8-bit relocation, but used to form an address like 0xFFnn.
1259 BFD_RELOC_32_PCREL_S2
1261 BFD_RELOC_16_PCREL_S2
1263 BFD_RELOC_23_PCREL_S2
1265 These PC-relative relocations are stored as word displacements -- i.e.,
1266 byte displacements shifted right two bits. The 30-bit word displacement
1267 (<<32_PCREL_S2>> -- 32 bits, shifted 2) is used on the SPARC. The signed
1268 16-bit displacement is used on the MIPS, and the 23-bit displacement is
1276 High 22 bits and low 10 bits of 32-bit value, placed into lower bits of
1277 the target word. These are used on the SPARC.
1284 For systems that allocate a Global Pointer register, these are
1285 displacements off that register. These relocation types are
1286 handled specially, because the value the register will have is
1287 decided relatively late.
1291 BFD_RELOC_I960_CALLJ
1293 Reloc types used for i960/b.out.
1298 BFD_RELOC_SPARC_WDISP22
1304 BFD_RELOC_SPARC_GOT10
1306 BFD_RELOC_SPARC_GOT13
1308 BFD_RELOC_SPARC_GOT22
1310 BFD_RELOC_SPARC_PC10
1312 BFD_RELOC_SPARC_PC22
1314 BFD_RELOC_SPARC_WPLT30
1316 BFD_RELOC_SPARC_COPY
1318 BFD_RELOC_SPARC_GLOB_DAT
1320 BFD_RELOC_SPARC_JMP_SLOT
1322 BFD_RELOC_SPARC_RELATIVE
1324 BFD_RELOC_SPARC_UA32
1326 SPARC ELF relocations. There is probably some overlap with other
1327 relocation types already defined.
1330 BFD_RELOC_SPARC_BASE13
1332 BFD_RELOC_SPARC_BASE22
1334 I think these are specific to SPARC a.out (e.g., Sun 4).
1344 BFD_RELOC_SPARC_OLO10
1346 BFD_RELOC_SPARC_HH22
1348 BFD_RELOC_SPARC_HM10
1350 BFD_RELOC_SPARC_LM22
1352 BFD_RELOC_SPARC_PC_HH22
1354 BFD_RELOC_SPARC_PC_HM10
1356 BFD_RELOC_SPARC_PC_LM22
1358 BFD_RELOC_SPARC_WDISP16
1360 BFD_RELOC_SPARC_WDISP19
1362 BFD_RELOC_SPARC_GLOB_JMP
1366 Some relocations we're using for SPARC V9 -- subject to change.
1369 BFD_RELOC_ALPHA_GPDISP_HI16
1371 Alpha ECOFF relocations. Some of these treat the symbol or "addend"
1372 in some special way.
1373 For GPDISP_HI16 ("gpdisp") relocations, the symbol is ignored when
1374 writing; when reading, it will be the absolute section symbol. The
1375 addend is the displacement in bytes of the "lda" instruction from
1376 the "ldah" instruction (which is at the address of this reloc).
1378 BFD_RELOC_ALPHA_GPDISP_LO16
1380 For GPDISP_LO16 ("ignore") relocations, the symbol is handled as
1381 with GPDISP_HI16 relocs. The addend is ignored when writing the
1382 relocations out, and is filled in with the file's GP value on
1383 reading, for convenience.
1386 BFD_RELOC_ALPHA_LITERAL
1388 BFD_RELOC_ALPHA_LITUSE
1390 The Alpha LITERAL/LITUSE relocs are produced by a symbol reference;
1391 the assembler turns it into a LDQ instruction to load the address of
1392 the symbol, and then fills in a register in the real instruction.
1394 The LITERAL reloc, at the LDQ instruction, refers to the .lita
1395 section symbol. The addend is ignored when writing, but is filled
1396 in with the file's GP value on reading, for convenience, as with the
1399 The LITUSE reloc, on the instruction using the loaded address, gives
1400 information to the linker that it might be able to use to optimize
1401 away some literal section references. The symbol is ignored (read
1402 as the absolute section symbol), and the "addend" indicates the type
1403 of instruction using the register:
1404 1 - "memory" fmt insn
1405 2 - byte-manipulation (byte offset reg)
1406 3 - jsr (target of branch)
1408 The GNU linker currently doesn't do any of this optimizing.
1411 BFD_RELOC_ALPHA_HINT
1413 The HINT relocation indicates a value that should be filled into the
1414 "hint" field of a jmp/jsr/ret instruction, for possible branch-
1415 prediction logic which may be provided on some processors.
1420 Bits 27..2 of the relocation address shifted right 2 bits;
1421 simple reloc otherwise.
1426 High 16 bits of 32-bit value; simple reloc.
1430 High 16 bits of 32-bit value but the low 16 bits will be sign
1431 extended and added to form the final result. If the low 16
1432 bits form a negative number, we need to add one to the high value
1433 to compensate for the borrow when the low bits are added.
1439 BFD_RELOC_PCREL_HI16_S
1441 Like BFD_RELOC_HI16_S, but PC relative.
1443 BFD_RELOC_PCREL_LO16
1445 Like BFD_RELOC_LO16, but PC relative.
1448 BFD_RELOC_MIPS_GPREL
1451 Relocation relative to the global pointer.
1454 BFD_RELOC_MIPS_LITERAL
1456 Relocation against a MIPS literal section.
1459 BFD_RELOC_MIPS_GOT16
1461 BFD_RELOC_MIPS_CALL16
1463 BFD_RELOC_MIPS_GPREL32
1466 MIPS ELF relocations.
1475 BFD_RELOC_386_GLOB_DAT
1477 BFD_RELOC_386_JUMP_SLOT
1479 BFD_RELOC_386_RELATIVE
1481 BFD_RELOC_386_GOTOFF
1485 i386/elf relocations
1488 BFD_RELOC_NS32K_IMM_8
1490 BFD_RELOC_NS32K_IMM_16
1492 BFD_RELOC_NS32K_IMM_32
1494 BFD_RELOC_NS32K_IMM_8_PCREL
1496 BFD_RELOC_NS32K_IMM_16_PCREL
1498 BFD_RELOC_NS32K_IMM_32_PCREL
1500 BFD_RELOC_NS32K_DISP_8
1502 BFD_RELOC_NS32K_DISP_16
1504 BFD_RELOC_NS32K_DISP_32
1506 BFD_RELOC_NS32K_DISP_8_PCREL
1508 BFD_RELOC_NS32K_DISP_16_PCREL
1510 BFD_RELOC_NS32K_DISP_32_PCREL
1517 PowerPC/POWER (RS/6000) relocs.
1518 26 bit relative branch. Low two bits must be zero. High 24
1519 bits installed in bits 6 through 29 of instruction.
1523 26 bit absolute branch, like BFD_RELOC_PPC_B26 but absolute.
1527 16 bit TOC relative reference.
1532 The type of reloc used to build a contructor table - at the moment
1533 probably a 32 bit wide absolute relocation, but the target can choose.
1534 It generally does map to one of the other relocation types.
1541 .typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
1547 bfd_reloc_type_lookup
1550 const struct reloc_howto_struct *
1551 bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code);
1554 Return a pointer to a howto structure which, when
1555 invoked, will perform the relocation @var{code} on data from the
1561 const struct reloc_howto_struct
*
1562 bfd_reloc_type_lookup (abfd
, code
)
1564 bfd_reloc_code_real_type code
;
1566 return BFD_SEND (abfd
, reloc_type_lookup
, (abfd
, code
));
1569 static reloc_howto_type bfd_howto_32
=
1570 HOWTO (0, 00, 2, 32, false, 0, complain_overflow_bitfield
, 0, "VRT32", false, 0xffffffff, 0xffffffff, true);
1575 bfd_default_reloc_type_lookup
1578 const struct reloc_howto_struct *bfd_default_reloc_type_lookup
1579 (bfd *abfd, bfd_reloc_code_real_type code);
1582 Provides a default relocation lookup routine for any architecture.
1587 const struct reloc_howto_struct
*
1588 bfd_default_reloc_type_lookup (abfd
, code
)
1590 bfd_reloc_code_real_type code
;
1594 case BFD_RELOC_CTOR
:
1595 /* The type of reloc used in a ctor, which will be as wide as the
1596 address - so either a 64, 32, or 16 bitter. */
1597 switch (bfd_get_arch_info (abfd
)->bits_per_address
)
1602 return &bfd_howto_32
;
1611 return (const struct reloc_howto_struct
*) NULL
;
1616 bfd_get_reloc_code_name
1619 const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code);
1622 Provides a printable name for the supplied relocation code.
1623 Useful mainly for printing error messages.
1627 bfd_get_reloc_code_name (code
)
1628 bfd_reloc_code_real_type code
;
1630 if (code
> BFD_RELOC_UNUSED
)
1632 return bfd_reloc_code_real_names
[(int)code
];
1637 bfd_generic_relax_section
1640 boolean bfd_generic_relax_section
1643 struct bfd_link_info *,
1647 Provides default handling for relaxing for back ends which
1648 don't do relaxing -- i.e., does nothing.
1653 bfd_generic_relax_section (abfd
, section
, link_info
, again
)
1656 struct bfd_link_info
*link_info
;
1665 bfd_generic_get_relocated_section_contents
1669 bfd_generic_get_relocated_section_contents (bfd *abfd,
1670 struct bfd_link_info *link_info,
1671 struct bfd_link_order *link_order,
1673 boolean relocateable,
1677 Provides default handling of relocation effort for back ends
1678 which can't be bothered to do it efficiently.
1683 bfd_generic_get_relocated_section_contents (abfd
, link_info
, link_order
, data
,
1684 relocateable
, symbols
)
1686 struct bfd_link_info
*link_info
;
1687 struct bfd_link_order
*link_order
;
1689 boolean relocateable
;
1692 /* Get enough memory to hold the stuff */
1693 bfd
*input_bfd
= link_order
->u
.indirect
.section
->owner
;
1694 asection
*input_section
= link_order
->u
.indirect
.section
;
1696 long reloc_size
= bfd_get_reloc_upper_bound (input_bfd
, input_section
);
1697 arelent
**reloc_vector
= NULL
;
1703 reloc_vector
= (arelent
**) malloc (reloc_size
);
1704 if (reloc_vector
== NULL
&& reloc_size
!= 0)
1706 bfd_set_error (bfd_error_no_memory
);
1710 /* read in the section */
1711 if (!bfd_get_section_contents (input_bfd
,
1715 input_section
->_raw_size
))
1718 /* We're not relaxing the section, so just copy the size info */
1719 input_section
->_cooked_size
= input_section
->_raw_size
;
1720 input_section
->reloc_done
= true;
1722 reloc_count
= bfd_canonicalize_reloc (input_bfd
,
1726 if (reloc_count
< 0)
1729 if (reloc_count
> 0)
1732 for (parent
= reloc_vector
; *parent
!= (arelent
*) NULL
;
1735 char *error_message
= (char *) NULL
;
1736 bfd_reloc_status_type r
=
1737 bfd_perform_relocation (input_bfd
,
1741 relocateable
? abfd
: (bfd
*) NULL
,
1746 asection
*os
= input_section
->output_section
;
1748 /* A partial link, so keep the relocs */
1749 os
->orelocation
[os
->reloc_count
] = *parent
;
1753 if (r
!= bfd_reloc_ok
)
1757 case bfd_reloc_undefined
:
1758 if (!((*link_info
->callbacks
->undefined_symbol
)
1759 (link_info
, bfd_asymbol_name (*(*parent
)->sym_ptr_ptr
),
1760 input_bfd
, input_section
, (*parent
)->address
)))
1763 case bfd_reloc_dangerous
:
1764 BFD_ASSERT (error_message
!= (char *) NULL
);
1765 if (!((*link_info
->callbacks
->reloc_dangerous
)
1766 (link_info
, error_message
, input_bfd
, input_section
,
1767 (*parent
)->address
)))
1770 case bfd_reloc_overflow
:
1771 if (!((*link_info
->callbacks
->reloc_overflow
)
1772 (link_info
, bfd_asymbol_name (*(*parent
)->sym_ptr_ptr
),
1773 (*parent
)->howto
->name
, (*parent
)->addend
,
1774 input_bfd
, input_section
, (*parent
)->address
)))
1777 case bfd_reloc_outofrange
:
1786 if (reloc_vector
!= NULL
)
1787 free (reloc_vector
);
1791 if (reloc_vector
!= NULL
)
1792 free (reloc_vector
);