/* BFD support for handling relocation entries.
- Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
+ Copyright (C) 1990, 91, 92, 93, 94, 95, 96, 97, 1998
+ Free Software Foundation, Inc.
Written by Cygnus Support.
This file is part of BFD, the Binary File Descriptor library.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
/*
SECTION
. bfd_vma addend;
.
. {* Pointer to how to perform the required relocation *}
-. const struct reloc_howto_struct *howto;
+. reloc_howto_type *howto;
.
.} arelent;
type which modifies the bottom two bytes of a four byte word
would not touch the first byte pointed to in a big endian
world.
-
+
o <<addend>>
The <<addend>> is a value provided by the back end to be added (!)
CODE_FRAGMENT
.struct symbol_cache_entry; {* Forward declaration *}
.
-.typedef unsigned char bfd_byte;
-.typedef struct reloc_howto_struct reloc_howto_type;
-.
.struct reloc_howto_struct
.{
-. {* The type field has mainly a documetary use - the back end can
+. {* The type field has mainly a documentary use - the back end can
. do what it wants with it, though normally the back end's
. external idea of what a reloc number is stored
. in this field. For example, a PC relative word relocation
bfd_get_reloc_size
SYNOPSIS
- int bfd_get_reloc_size (const reloc_howto_type *);
+ unsigned int bfd_get_reloc_size (reloc_howto_type *);
DESCRIPTION
For a reloc_howto_type that operates on a fixed number of bytes,
this returns the number of bytes operated on.
*/
-int
+unsigned int
bfd_get_reloc_size (howto)
- const reloc_howto_type *howto;
+ reloc_howto_type *howto;
{
switch (howto->size)
{
case 2: return 4;
case 3: return 0;
case 4: return 8;
+ case 8: return 16;
case -2: return 4;
default: abort ();
}
*/
+/*
+FUNCTION
+ bfd_check_overflow
+
+SYNOPSIS
+ bfd_reloc_status_type
+ bfd_check_overflow
+ (enum complain_overflow how,
+ unsigned int bitsize,
+ unsigned int rightshift,
+ bfd_vma relocation);
+
+DESCRIPTION
+ Perform overflow checking on @var{relocation} which has @var{bitsize}
+ significant bits and will be shifted right by @var{rightshift} bits.
+ The result is either of @code{bfd_reloc_ok} or
+ @code{bfd_reloc_overflow}.
+
+*/
+
+bfd_reloc_status_type
+bfd_check_overflow (how, bitsize, rightshift, relocation)
+ enum complain_overflow how;
+ unsigned int bitsize, rightshift;
+ bfd_vma relocation;
+{
+ bfd_vma check;
+ bfd_reloc_status_type flag = bfd_reloc_ok;
+
+ /* Get the value that will be used for the relocation, but
+ starting at bit position zero. */
+ check = relocation >> rightshift;
+
+ switch (how)
+ {
+ case complain_overflow_dont:
+ break;
+
+ case complain_overflow_signed:
+ {
+ /* Assumes two's complement. */
+ bfd_signed_vma reloc_signed_max =
+ ((bfd_signed_vma) 1 << (bitsize - 1)) - 1;
+ bfd_signed_vma reloc_signed_min = ~reloc_signed_max;
+
+ /* The above right shift is incorrect for a signed value.
+ Fix it up by forcing on the upper bits. */
+ if (rightshift > 0
+ && (bfd_signed_vma) relocation < 0)
+ check |= ((bfd_vma) - 1
+ & ~((bfd_vma) - 1
+ >> rightshift));
+ if ((bfd_signed_vma) check > reloc_signed_max
+ || (bfd_signed_vma) check < reloc_signed_min)
+ flag = bfd_reloc_overflow;
+ }
+ break;
+
+ case complain_overflow_unsigned:
+ {
+ /* Assumes two's complement. This expression avoids
+ overflow if `bitsize' is the number of bits in
+ bfd_vma. */
+ bfd_vma reloc_unsigned_max =
+ ((((bfd_vma) 1 << (bitsize - 1)) - 1) << 1) | 1;
+
+ if ((bfd_vma) check > reloc_unsigned_max)
+ flag = bfd_reloc_overflow;
+ }
+ break;
+
+ case complain_overflow_bitfield:
+ {
+ /* Assumes two's complement. This expression avoids
+ overflow if `bitsize' is the number of bits in
+ bfd_vma. */
+ bfd_vma reloc_bits = (((1 << (bitsize - 1)) - 1) << 1) | 1;
+
+ if (((bfd_vma) check & ~reloc_bits) != 0
+ && ((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits))
+ {
+ /* The above right shift is incorrect for a signed
+ value. See if turning on the upper bits fixes the
+ overflow. */
+ if (rightshift > 0
+ && (bfd_signed_vma) relocation < 0)
+ {
+ check |= ((bfd_vma) - 1
+ & ~((bfd_vma) - 1
+ >> rightshift));
+ if (((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits))
+ flag = bfd_reloc_overflow;
+ }
+ else
+ flag = bfd_reloc_overflow;
+ }
+ }
+ break;
+
+ default:
+ abort ();
+ }
+
+ return flag;
+}
+
/*
FUNCTION
bfd_reloc_status_type flag = bfd_reloc_ok;
bfd_size_type addr = reloc_entry->address;
bfd_vma output_base = 0;
- const reloc_howto_type *howto = reloc_entry->howto;
+ reloc_howto_type *howto = reloc_entry->howto;
asection *reloc_target_output_section;
asymbol *symbol;
/* WTF?? */
if (abfd->xvec->flavour == bfd_target_coff_flavour
&& strcmp (abfd->xvec->name, "aixcoff-rs6000") != 0
+ && strcmp (abfd->xvec->name, "xcoff-powermac") != 0
&& strcmp (abfd->xvec->name, "coff-Intel-little") != 0
&& strcmp (abfd->xvec->name, "coff-Intel-big") != 0)
{
machine word.
FIXME: We should also do overflow checking on the result after
adding in the value contained in the object file. */
- if (howto->complain_on_overflow != complain_overflow_dont)
- {
- bfd_vma check;
-
- /* Get the value that will be used for the relocation, but
- starting at bit position zero. */
- if (howto->rightshift > howto->bitpos)
- check = relocation >> (howto->rightshift - howto->bitpos);
- else
- check = relocation << (howto->bitpos - howto->rightshift);
- switch (howto->complain_on_overflow)
- {
- case complain_overflow_signed:
- {
- /* Assumes two's complement. */
- bfd_signed_vma reloc_signed_max = (1 << (howto->bitsize - 1)) - 1;
- bfd_signed_vma reloc_signed_min = ~reloc_signed_max;
-
- /* The above right shift is incorrect for a signed value.
- Fix it up by forcing on the upper bits. */
- if (howto->rightshift > howto->bitpos
- && (bfd_signed_vma) relocation < 0)
- check |= ((bfd_vma) - 1
- & ~((bfd_vma) - 1
- >> (howto->rightshift - howto->bitpos)));
- if ((bfd_signed_vma) check > reloc_signed_max
- || (bfd_signed_vma) check < reloc_signed_min)
- flag = bfd_reloc_overflow;
- }
- break;
- case complain_overflow_unsigned:
- {
- /* Assumes two's complement. This expression avoids
- overflow if howto->bitsize is the number of bits in
- bfd_vma. */
- bfd_vma reloc_unsigned_max =
- (((1 << (howto->bitsize - 1)) - 1) << 1) | 1;
-
- if ((bfd_vma) check > reloc_unsigned_max)
- flag = bfd_reloc_overflow;
- }
- break;
- case complain_overflow_bitfield:
- {
- /* Assumes two's complement. This expression avoids
- overflow if howto->bitsize is the number of bits in
- bfd_vma. */
- bfd_vma reloc_bits = (((1 << (howto->bitsize - 1)) - 1) << 1) | 1;
-
- if (((bfd_vma) check & ~reloc_bits) != 0
- && ((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits))
- {
- /* The above right shift is incorrect for a signed
- value. See if turning on the upper bits fixes the
- overflow. */
- if (howto->rightshift > howto->bitpos
- && (bfd_signed_vma) relocation < 0)
- {
- check |= ((bfd_vma) - 1
- & ~((bfd_vma) - 1
- >> (howto->rightshift - howto->bitpos)));
- if (((bfd_vma) check & ~reloc_bits) != (-1 & ~reloc_bits))
- flag = bfd_reloc_overflow;
- }
- else
- flag = bfd_reloc_overflow;
- }
- }
- break;
- default:
- abort ();
- }
- }
+ if (howto->complain_on_overflow != complain_overflow_dont
+ && flag == bfd_reloc_ok)
+ flag = bfd_check_overflow (howto->complain_on_overflow, howto->bitsize,
+ howto->rightshift, relocation);
/*
Either we are relocating all the way, or we don't want to apply
break;
case 1:
- if (relocation)
- {
- short x = bfd_get_16 (abfd, (bfd_byte *) data + addr);
- DOIT (x);
- bfd_put_16 (abfd, x, (unsigned char *) data + addr);
- }
+ {
+ short x = bfd_get_16 (abfd, (bfd_byte *) data + addr);
+ DOIT (x);
+ bfd_put_16 (abfd, x, (unsigned char *) data + addr);
+ }
break;
case 2:
- if (relocation)
- {
- long x = bfd_get_32 (abfd, (bfd_byte *) data + addr);
- DOIT (x);
- bfd_put_32 (abfd, x, (bfd_byte *) data + addr);
- }
+ {
+ long x = bfd_get_32 (abfd, (bfd_byte *) data + addr);
+ DOIT (x);
+ bfd_put_32 (abfd, x, (bfd_byte *) data + addr);
+ }
break;
case -2:
{
}
break;
+ case -1:
+ {
+ long x = bfd_get_16 (abfd, (bfd_byte *) data + addr);
+ relocation = -relocation;
+ DOIT (x);
+ bfd_put_16 (abfd, x, (bfd_byte *) data + addr);
+ }
+ break;
+
case 3:
/* Do nothing */
break;
case 4:
#ifdef BFD64
- if (relocation)
- {
- bfd_vma x = bfd_get_64 (abfd, (bfd_byte *) data + addr);
- DOIT (x);
- bfd_put_64 (abfd, x, (bfd_byte *) data + addr);
- }
+ {
+ bfd_vma x = bfd_get_64 (abfd, (bfd_byte *) data + addr);
+ DOIT (x);
+ bfd_put_64 (abfd, x, (bfd_byte *) data + addr);
+ }
#else
abort ();
#endif
return flag;
}
-/* This relocation routine is used by some of the backend linkers.
- They do not construct asymbol or arelent structures, so there is no
- reason for them to use bfd_perform_relocation. Also,
- bfd_perform_relocation is so hacked up it is easier to write a new
- function than to try to deal with it.
+/*
+FUNCTION
+ bfd_install_relocation
- This routine does a final relocation. It should not be used when
- generating relocateable output.
+SYNOPSIS
+ bfd_reloc_status_type
+ bfd_install_relocation
+ (bfd *abfd,
+ arelent *reloc_entry,
+ PTR data, bfd_vma data_start,
+ asection *input_section,
+ char **error_message);
- FIXME: This routine ignores any special_function in the HOWTO,
- since the existing special_function values have been written for
- bfd_perform_relocation.
+DESCRIPTION
+ This looks remarkably like <<bfd_perform_relocation>>, except it
+ does not expect that the section contents have been filled in.
+ I.e., it's suitable for use when creating, rather than applying
+ a relocation.
+
+ For now, this function should be considered reserved for the
+ assembler.
+
+*/
- HOWTO is the reloc howto information.
- INPUT_BFD is the BFD which the reloc applies to.
- INPUT_SECTION is the section which the reloc applies to.
- CONTENTS is the contents of the section.
- ADDRESS is the address of the reloc within INPUT_SECTION.
- VALUE is the value of the symbol the reloc refers to.
- ADDEND is the addend of the reloc. */
bfd_reloc_status_type
-_bfd_final_link_relocate (howto, input_bfd, input_section, contents, address,
- value, addend)
- const reloc_howto_type *howto;
- bfd *input_bfd;
+bfd_install_relocation (abfd, reloc_entry, data_start, data_start_offset,
+ input_section, error_message)
+ bfd *abfd;
+ arelent *reloc_entry;
+ PTR data_start;
+ bfd_vma data_start_offset;
asection *input_section;
- bfd_byte *contents;
- bfd_vma address;
- bfd_vma value;
- bfd_vma addend;
+ char **error_message;
{
bfd_vma relocation;
+ bfd_reloc_status_type flag = bfd_reloc_ok;
+ bfd_size_type addr = reloc_entry->address;
+ bfd_vma output_base = 0;
+ reloc_howto_type *howto = reloc_entry->howto;
+ asection *reloc_target_output_section;
+ asymbol *symbol;
+ bfd_byte *data;
- /* Sanity check the address. */
- if (address > input_section->_cooked_size)
- return bfd_reloc_outofrange;
-
- /* This function assumes that we are dealing with a basic relocation
- against a symbol. We want to compute the value of the symbol to
- relocate to. This is just VALUE, the value of the symbol, plus
- ADDEND, any addend associated with the reloc. */
- relocation = value + addend;
+ symbol = *(reloc_entry->sym_ptr_ptr);
+ if (bfd_is_abs_section (symbol->section))
+ {
+ reloc_entry->address += input_section->output_offset;
+ return bfd_reloc_ok;
+ }
- /* If the relocation is PC relative, we want to set RELOCATION to
- the distance between the symbol (currently in RELOCATION) and the
- location we are relocating. Some targets (e.g., i386-aout)
- arrange for the contents of the section to be the negative of the
- offset of the location within the section; for such targets
- pcrel_offset is false. Other targets (e.g., m88kbcs or ELF)
- simply leave the contents of the section as zero; for such
- targets pcrel_offset is true. If pcrel_offset is false we do not
- need to subtract out the offset of the location within the
- section (which is just ADDRESS). */
- if (howto->pc_relative)
+ /* If there is a function supplied to handle this relocation type,
+ call it. It'll return `bfd_reloc_continue' if further processing
+ can be done. */
+ if (howto->special_function)
{
- relocation -= (input_section->output_section->vma
- + input_section->output_offset);
- if (howto->pcrel_offset)
- relocation -= address;
+ bfd_reloc_status_type cont;
+
+ /* XXX - The special_function calls haven't been fixed up to deal
+ with creating new relocations and section contents. */
+ cont = howto->special_function (abfd, reloc_entry, symbol,
+ /* XXX - Non-portable! */
+ ((bfd_byte *) data_start
+ - data_start_offset),
+ input_section, abfd, error_message);
+ if (cont != bfd_reloc_continue)
+ return cont;
}
- return _bfd_relocate_contents (howto, input_bfd, relocation,
- contents + address);
-}
+ /* Is the address of the relocation really within the section? */
+ if (reloc_entry->address > input_section->_cooked_size)
+ return bfd_reloc_outofrange;
-/* Relocate a given location using a given value and howto. */
+ /* Work out which section the relocation is targetted at and the
+ initial relocation command value. */
-bfd_reloc_status_type
-_bfd_relocate_contents (howto, input_bfd, relocation, location)
- const reloc_howto_type *howto;
- bfd *input_bfd;
- bfd_vma relocation;
- bfd_byte *location;
-{
- int size;
- bfd_vma x;
- boolean overflow;
+ /* Get symbol value. (Common symbols are special.) */
+ if (bfd_is_com_section (symbol->section))
+ relocation = 0;
+ else
+ relocation = symbol->value;
- /* If the size is negative, negate RELOCATION. This isn't very
- general. */
- if (howto->size < 0)
- relocation = -relocation;
+ reloc_target_output_section = symbol->section->output_section;
- /* Get the value we are going to relocate. */
- size = bfd_get_reloc_size (howto);
- switch (size)
- {
- default:
- case 0:
- abort ();
- case 1:
- x = bfd_get_8 (input_bfd, location);
- break;
- case 2:
- x = bfd_get_16 (input_bfd, location);
- break;
- case 4:
- x = bfd_get_32 (input_bfd, location);
- break;
- case 8:
-#ifdef BFD64
- x = bfd_get_64 (input_bfd, location);
-#else
- abort ();
-#endif
- break;
- }
+ /* Convert input-section-relative symbol value to absolute. */
+ if (howto->partial_inplace == false)
+ output_base = 0;
+ else
+ output_base = reloc_target_output_section->vma;
- /* Check for overflow. FIXME: We may drop bits during the addition
- which we don't check for. We must either check at every single
- operation, which would be tedious, or we must do the computations
- in a type larger than bfd_vma, which would be inefficient. */
- overflow = false;
- if (howto->complain_on_overflow != complain_overflow_dont)
- {
- bfd_vma check;
- bfd_signed_vma signed_check;
- bfd_vma add;
+ relocation += output_base + symbol->section->output_offset;
+
+ /* Add in supplied addend. */
+ relocation += reloc_entry->addend;
+
+ /* Here the variable relocation holds the final address of the
+ symbol we are relocating against, plus any addend. */
+
+ if (howto->pc_relative == true)
+ {
+ /* This is a PC relative relocation. We want to set RELOCATION
+ to the distance between the address of the symbol and the
+ location. RELOCATION is already the address of the symbol.
+
+ We start by subtracting the address of the section containing
+ the location.
+
+ If pcrel_offset is set, we must further subtract the position
+ of the location within the section. Some targets arrange for
+ the addend to be the negative of the position of the location
+ within the section; for example, i386-aout does this. For
+ i386-aout, pcrel_offset is false. Some other targets do not
+ include the position of the location; for example, m88kbcs,
+ or ELF. For those targets, pcrel_offset is true.
+
+ If we are producing relocateable output, then we must ensure
+ that this reloc will be correctly computed when the final
+ relocation is done. If pcrel_offset is false we want to wind
+ up with the negative of the location within the section,
+ which means we must adjust the existing addend by the change
+ in the location within the section. If pcrel_offset is true
+ we do not want to adjust the existing addend at all.
+
+ FIXME: This seems logical to me, but for the case of
+ producing relocateable output it is not what the code
+ actually does. I don't want to change it, because it seems
+ far too likely that something will break. */
+
+ relocation -=
+ input_section->output_section->vma + input_section->output_offset;
+
+ if (howto->pcrel_offset == true && howto->partial_inplace == true)
+ relocation -= reloc_entry->address;
+ }
+
+ if (howto->partial_inplace == false)
+ {
+ /* This is a partial relocation, and we want to apply the relocation
+ to the reloc entry rather than the raw data. Modify the reloc
+ inplace to reflect what we now know. */
+ reloc_entry->addend = relocation;
+ reloc_entry->address += input_section->output_offset;
+ return flag;
+ }
+ else
+ {
+ /* This is a partial relocation, but inplace, so modify the
+ reloc record a bit.
+
+ If we've relocated with a symbol with a section, change
+ into a ref to the section belonging to the symbol. */
+
+ reloc_entry->address += input_section->output_offset;
+
+ /* WTF?? */
+ if (abfd->xvec->flavour == bfd_target_coff_flavour
+ && strcmp (abfd->xvec->name, "aixcoff-rs6000") != 0
+ && strcmp (abfd->xvec->name, "xcoff-powermac") != 0
+ && strcmp (abfd->xvec->name, "coff-Intel-little") != 0
+ && strcmp (abfd->xvec->name, "coff-Intel-big") != 0)
+ {
+#if 1
+/* For m68k-coff, the addend was being subtracted twice during
+ relocation with -r. Removing the line below this comment
+ fixes that problem; see PR 2953.
+
+However, Ian wrote the following, regarding removing the line below,
+which explains why it is still enabled: --djm
+
+If you put a patch like that into BFD you need to check all the COFF
+linkers. I am fairly certain that patch will break coff-i386 (e.g.,
+SCO); see coff_i386_reloc in coff-i386.c where I worked around the
+problem in a different way. There may very well be a reason that the
+code works as it does.
+
+Hmmm. The first obvious point is that bfd_install_relocation should
+not have any tests that depend upon the flavour. It's seem like
+entirely the wrong place for such a thing. The second obvious point
+is that the current code ignores the reloc addend when producing
+relocateable output for COFF. That's peculiar. In fact, I really
+have no idea what the point of the line you want to remove is.
+
+A typical COFF reloc subtracts the old value of the symbol and adds in
+the new value to the location in the object file (if it's a pc
+relative reloc it adds the difference between the symbol value and the
+location). When relocating we need to preserve that property.
+
+BFD handles this by setting the addend to the negative of the old
+value of the symbol. Unfortunately it handles common symbols in a
+non-standard way (it doesn't subtract the old value) but that's a
+different story (we can't change it without losing backward
+compatibility with old object files) (coff-i386 does subtract the old
+value, to be compatible with existing coff-i386 targets, like SCO).
+
+So everything works fine when not producing relocateable output. When
+we are producing relocateable output, logically we should do exactly
+what we do when not producing relocateable output. Therefore, your
+patch is correct. In fact, it should probably always just set
+reloc_entry->addend to 0 for all cases, since it is, in fact, going to
+add the value into the object file. This won't hurt the COFF code,
+which doesn't use the addend; I'm not sure what it will do to other
+formats (the thing to check for would be whether any formats both use
+the addend and set partial_inplace).
+
+When I wanted to make coff-i386 produce relocateable output, I ran
+into the problem that you are running into: I wanted to remove that
+line. Rather than risk it, I made the coff-i386 relocs use a special
+function; it's coff_i386_reloc in coff-i386.c. The function
+specifically adds the addend field into the object file, knowing that
+bfd_install_relocation is not going to. If you remove that line, then
+coff-i386.c will wind up adding the addend field in twice. It's
+trivial to fix; it just needs to be done.
+
+The problem with removing the line is just that it may break some
+working code. With BFD it's hard to be sure of anything. The right
+way to deal with this is simply to build and test at least all the
+supported COFF targets. It should be straightforward if time and disk
+space consuming. For each target:
+ 1) build the linker
+ 2) generate some executable, and link it using -r (I would
+ probably use paranoia.o and link against newlib/libc.a, which
+ for all the supported targets would be available in
+ /usr/cygnus/progressive/H-host/target/lib/libc.a).
+ 3) make the change to reloc.c
+ 4) rebuild the linker
+ 5) repeat step 2
+ 6) if the resulting object files are the same, you have at least
+ made it no worse
+ 7) if they are different you have to figure out which version is
+ right
+*/
+ relocation -= reloc_entry->addend;
+#endif
+ reloc_entry->addend = 0;
+ }
+ else
+ {
+ reloc_entry->addend = relocation;
+ }
+ }
+
+ /* FIXME: This overflow checking is incomplete, because the value
+ might have overflowed before we get here. For a correct check we
+ need to compute the value in a size larger than bitsize, but we
+ can't reasonably do that for a reloc the same size as a host
+ machine word.
+ FIXME: We should also do overflow checking on the result after
+ adding in the value contained in the object file. */
+ if (howto->complain_on_overflow != complain_overflow_dont)
+ flag = bfd_check_overflow (howto->complain_on_overflow, howto->bitsize,
+ howto->rightshift, relocation);
+
+ /*
+ Either we are relocating all the way, or we don't want to apply
+ the relocation to the reloc entry (probably because there isn't
+ any room in the output format to describe addends to relocs)
+ */
+
+ /* The cast to bfd_vma avoids a bug in the Alpha OSF/1 C compiler
+ (OSF version 1.3, compiler version 3.11). It miscompiles the
+ following program:
+
+ struct str
+ {
+ unsigned int i0;
+ } s = { 0 };
+
+ int
+ main ()
+ {
+ unsigned long x;
+
+ x = 0x100000000;
+ x <<= (unsigned long) s.i0;
+ if (x == 0)
+ printf ("failed\n");
+ else
+ printf ("succeeded (%lx)\n", x);
+ }
+ */
+
+ relocation >>= (bfd_vma) howto->rightshift;
+
+ /* Shift everything up to where it's going to be used */
+
+ relocation <<= (bfd_vma) howto->bitpos;
+
+ /* Wait for the day when all have the mask in them */
+
+ /* What we do:
+ i instruction to be left alone
+ o offset within instruction
+ r relocation offset to apply
+ S src mask
+ D dst mask
+ N ~dst mask
+ A part 1
+ B part 2
+ R result
+
+ Do this:
+ i i i i i o o o o o from bfd_get<size>
+ and S S S S S to get the size offset we want
+ + r r r r r r r r r r to get the final value to place
+ and D D D D D to chop to right size
+ -----------------------
+ A A A A A
+ And this:
+ ... i i i i i o o o o o from bfd_get<size>
+ and N N N N N get instruction
+ -----------------------
+ ... B B B B B
+
+ And then:
+ B B B B B
+ or A A A A A
+ -----------------------
+ R R R R R R R R R R put into bfd_put<size>
+ */
+
+#define DOIT(x) \
+ x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask))
+
+ data = (bfd_byte *) data_start + (addr - data_start_offset);
+
+ switch (howto->size)
+ {
+ case 0:
+ {
+ char x = bfd_get_8 (abfd, (char *) data);
+ DOIT (x);
+ bfd_put_8 (abfd, x, (unsigned char *) data);
+ }
+ break;
+
+ case 1:
+ {
+ short x = bfd_get_16 (abfd, (bfd_byte *) data);
+ DOIT (x);
+ bfd_put_16 (abfd, x, (unsigned char *) data);
+ }
+ break;
+ case 2:
+ {
+ long x = bfd_get_32 (abfd, (bfd_byte *) data);
+ DOIT (x);
+ bfd_put_32 (abfd, x, (bfd_byte *) data);
+ }
+ break;
+ case -2:
+ {
+ long x = bfd_get_32 (abfd, (bfd_byte *) data);
+ relocation = -relocation;
+ DOIT (x);
+ bfd_put_32 (abfd, x, (bfd_byte *) data);
+ }
+ break;
+
+ case 3:
+ /* Do nothing */
+ break;
+
+ case 4:
+ {
+ bfd_vma x = bfd_get_64 (abfd, (bfd_byte *) data);
+ DOIT (x);
+ bfd_put_64 (abfd, x, (bfd_byte *) data);
+ }
+ break;
+ default:
+ return bfd_reloc_other;
+ }
+
+ return flag;
+}
+
+/* This relocation routine is used by some of the backend linkers.
+ They do not construct asymbol or arelent structures, so there is no
+ reason for them to use bfd_perform_relocation. Also,
+ bfd_perform_relocation is so hacked up it is easier to write a new
+ function than to try to deal with it.
+
+ This routine does a final relocation. Whether it is useful for a
+ relocateable link depends upon how the object format defines
+ relocations.
+
+ FIXME: This routine ignores any special_function in the HOWTO,
+ since the existing special_function values have been written for
+ bfd_perform_relocation.
+
+ HOWTO is the reloc howto information.
+ INPUT_BFD is the BFD which the reloc applies to.
+ INPUT_SECTION is the section which the reloc applies to.
+ CONTENTS is the contents of the section.
+ ADDRESS is the address of the reloc within INPUT_SECTION.
+ VALUE is the value of the symbol the reloc refers to.
+ ADDEND is the addend of the reloc. */
+
+bfd_reloc_status_type
+_bfd_final_link_relocate (howto, input_bfd, input_section, contents, address,
+ value, addend)
+ reloc_howto_type *howto;
+ bfd *input_bfd;
+ asection *input_section;
+ bfd_byte *contents;
+ bfd_vma address;
+ bfd_vma value;
+ bfd_vma addend;
+{
+ bfd_vma relocation;
+
+ /* Sanity check the address. */
+ if (address > input_section->_raw_size)
+ return bfd_reloc_outofrange;
+
+ /* This function assumes that we are dealing with a basic relocation
+ against a symbol. We want to compute the value of the symbol to
+ relocate to. This is just VALUE, the value of the symbol, plus
+ ADDEND, any addend associated with the reloc. */
+ relocation = value + addend;
+
+ /* If the relocation is PC relative, we want to set RELOCATION to
+ the distance between the symbol (currently in RELOCATION) and the
+ location we are relocating. Some targets (e.g., i386-aout)
+ arrange for the contents of the section to be the negative of the
+ offset of the location within the section; for such targets
+ pcrel_offset is false. Other targets (e.g., m88kbcs or ELF)
+ simply leave the contents of the section as zero; for such
+ targets pcrel_offset is true. If pcrel_offset is false we do not
+ need to subtract out the offset of the location within the
+ section (which is just ADDRESS). */
+ if (howto->pc_relative)
+ {
+ relocation -= (input_section->output_section->vma
+ + input_section->output_offset);
+ if (howto->pcrel_offset)
+ relocation -= address;
+ }
+
+ return _bfd_relocate_contents (howto, input_bfd, relocation,
+ contents + address);
+}
+
+/* Relocate a given location using a given value and howto. */
+
+bfd_reloc_status_type
+_bfd_relocate_contents (howto, input_bfd, relocation, location)
+ reloc_howto_type *howto;
+ bfd *input_bfd;
+ bfd_vma relocation;
+ bfd_byte *location;
+{
+ int size;
+ bfd_vma x;
+ boolean overflow;
+
+ /* If the size is negative, negate RELOCATION. This isn't very
+ general. */
+ if (howto->size < 0)
+ relocation = -relocation;
+
+ /* Get the value we are going to relocate. */
+ size = bfd_get_reloc_size (howto);
+ switch (size)
+ {
+ default:
+ case 0:
+ abort ();
+ case 1:
+ x = bfd_get_8 (input_bfd, location);
+ break;
+ case 2:
+ x = bfd_get_16 (input_bfd, location);
+ break;
+ case 4:
+ x = bfd_get_32 (input_bfd, location);
+ break;
+ case 8:
+#ifdef BFD64
+ x = bfd_get_64 (input_bfd, location);
+#else
+ abort ();
+#endif
+ break;
+ }
+
+ /* Check for overflow. FIXME: We may drop bits during the addition
+ which we don't check for. We must either check at every single
+ operation, which would be tedious, or we must do the computations
+ in a type larger than bfd_vma, which would be inefficient. */
+ overflow = false;
+ if (howto->complain_on_overflow != complain_overflow_dont)
+ {
+ bfd_vma check;
+ bfd_signed_vma signed_check;
+ bfd_vma add;
bfd_signed_vma signed_add;
if (howto->rightshift == 0)
case complain_overflow_signed:
{
/* Assumes two's complement. */
- bfd_signed_vma reloc_signed_max = (1 << (howto->bitsize - 1)) - 1;
+ bfd_signed_vma reloc_signed_max =
+ ((bfd_signed_vma) 1 << (howto->bitsize - 1)) - 1;
bfd_signed_vma reloc_signed_min = ~reloc_signed_max;
if (signed_check > reloc_signed_max
overflow if howto->bitsize is the number of bits in
bfd_vma. */
bfd_vma reloc_unsigned_max =
- (((1 << (howto->bitsize - 1)) - 1) << 1) | 1;
+ ((((bfd_vma) 1 << (howto->bitsize - 1)) - 1) << 1) | 1;
if (check > reloc_unsigned_max)
overflow = true;
BFD_RELOC_32
ENUMX
BFD_RELOC_26
+ENUMX
+ BFD_RELOC_24
ENUMX
BFD_RELOC_16
ENUMX
ENUMX
BFD_RELOC_16_PCREL
ENUMX
- BFD_RELOC_8_PCREL
+ BFD_RELOC_12_PCREL
+ENUMX
+ BFD_RELOC_8_PCREL
+ENUMDOC
+ PC-relative relocations. Sometimes these are relative to the address
+of the relocation itself; sometimes they are relative to the start of
+the section containing the relocation. It depends on the specific target.
+
+The 24-bit relocation is used in some Intel 960 configurations.
+
+ENUM
+ BFD_RELOC_32_GOT_PCREL
+ENUMX
+ BFD_RELOC_16_GOT_PCREL
+ENUMX
+ BFD_RELOC_8_GOT_PCREL
+ENUMX
+ BFD_RELOC_32_GOTOFF
+ENUMX
+ BFD_RELOC_16_GOTOFF
+ENUMX
+ BFD_RELOC_LO16_GOTOFF
+ENUMX
+ BFD_RELOC_HI16_GOTOFF
+ENUMX
+ BFD_RELOC_HI16_S_GOTOFF
+ENUMX
+ BFD_RELOC_8_GOTOFF
+ENUMX
+ BFD_RELOC_32_PLT_PCREL
+ENUMX
+ BFD_RELOC_24_PLT_PCREL
+ENUMX
+ BFD_RELOC_16_PLT_PCREL
+ENUMX
+ BFD_RELOC_8_PLT_PCREL
+ENUMX
+ BFD_RELOC_32_PLTOFF
+ENUMX
+ BFD_RELOC_16_PLTOFF
+ENUMX
+ BFD_RELOC_LO16_PLTOFF
+ENUMX
+ BFD_RELOC_HI16_PLTOFF
+ENUMX
+ BFD_RELOC_HI16_S_PLTOFF
+ENUMX
+ BFD_RELOC_8_PLTOFF
ENUMDOC
- PC-relative relocations. Sometimes these are relative to the address
-of the relocation itself; sometimes they are relative to the start of
-the section containing the relocation. It depends on the specific target.
+ For ELF.
-The 24-bit relocation is used in some Intel 960 configurations.
+ENUM
+ BFD_RELOC_68K_GLOB_DAT
+ENUMX
+ BFD_RELOC_68K_JMP_SLOT
+ENUMX
+ BFD_RELOC_68K_RELATIVE
+ENUMDOC
+ Relocations used by 68K ELF.
ENUM
BFD_RELOC_32_BASEREL
ENUMX
BFD_RELOC_16_BASEREL
+ENUMX
+ BFD_RELOC_LO16_BASEREL
+ENUMX
+ BFD_RELOC_HI16_BASEREL
+ENUMX
+ BFD_RELOC_HI16_S_BASEREL
ENUMX
BFD_RELOC_8_BASEREL
+ENUMX
+ BFD_RELOC_RVA
ENUMDOC
Linkage-table relative.
ENUMX
BFD_RELOC_23_PCREL_S2
ENUMDOC
- These PC-relative relocations are stored as word displacements -- i.e.,
-byte displacements shifted right two bits. The 30-bit word displacement
-(<<32_PCREL_S2>> -- 32 bits, shifted 2) is used on the SPARC. The signed
-16-bit displacement is used on the MIPS, and the 23-bit displacement is
-used on the Alpha.
+ These PC-relative relocations are stored as word displacements --
+i.e., byte displacements shifted right two bits. The 30-bit word
+displacement (<<32_PCREL_S2>> -- 32 bits, shifted 2) is used on the
+SPARC. (SPARC tools generally refer to this as <<WDISP30>>.) The
+signed 16-bit displacement is used on the MIPS, and the 23-bit
+displacement is used on the Alpha.
ENUM
BFD_RELOC_HI22
ENUMX
BFD_RELOC_SPARC_WDISP19
ENUMX
- BFD_RELOC_SPARC_GLOB_JMP
+ BFD_RELOC_SPARC_7
+ENUMX
+ BFD_RELOC_SPARC_6
+ENUMX
+ BFD_RELOC_SPARC_5
+ENUMEQX
+ BFD_RELOC_SPARC_DISP64
+ BFD_RELOC_64_PCREL
+ENUMX
+ BFD_RELOC_SPARC_PLT64
+ENUMX
+ BFD_RELOC_SPARC_HIX22
+ENUMX
+ BFD_RELOC_SPARC_LOX10
ENUMX
- BFD_RELOC_SPARC_LO7
+ BFD_RELOC_SPARC_H44
+ENUMX
+ BFD_RELOC_SPARC_M44
+ENUMX
+ BFD_RELOC_SPARC_L44
+ENUMX
+ BFD_RELOC_SPARC_REGISTER
+ENUMDOC
+ SPARC64 relocations
+
+ENUM
+ BFD_RELOC_SPARC_32LE
ENUMDOC
- Some relocations we're using for SPARC V9 -- subject to change.
+ SPARC little endian relocation
ENUM
BFD_RELOC_ALPHA_GPDISP_HI16
ENUMDOC
- Alpha ECOFF relocations. Some of these treat the symbol or "addend"
- in some special way.
+ Alpha ECOFF and ELF relocations. Some of these treat the symbol or
+ "addend" in some special way.
For GPDISP_HI16 ("gpdisp") relocations, the symbol is ignored when
writing; when reading, it will be the absolute section symbol. The
addend is the displacement in bytes of the "lda" instruction from
relocations out, and is filled in with the file's GP value on
reading, for convenience.
+ENUM
+ BFD_RELOC_ALPHA_GPDISP
+ENUMDOC
+ The ELF GPDISP relocation is exactly the same as the GPDISP_HI16
+ relocation except that there is no accompanying GPDISP_LO16
+ relocation.
+
ENUM
BFD_RELOC_ALPHA_LITERAL
+ENUMX
+ BFD_RELOC_ALPHA_ELF_LITERAL
ENUMX
BFD_RELOC_ALPHA_LITUSE
ENUMDOC
in with the file's GP value on reading, for convenience, as with the
GPDISP_LO16 reloc.
+ The ELF_LITERAL reloc is somewhere between 16_GOTOFF and GPDISP_LO16.
+ It should refer to the symbol to be referenced, as with 16_GOTOFF,
+ but it generates output not based on the position within the .got
+ section, but relative to the GP value chosen for the file during the
+ final link stage.
+
The LITUSE reloc, on the instruction using the loaded address, gives
information to the linker that it might be able to use to optimize
away some literal section references. The symbol is ignored (read
"hint" field of a jmp/jsr/ret instruction, for possible branch-
prediction logic which may be provided on some processors.
+ENUM
+ BFD_RELOC_ALPHA_LINKAGE
+ENUMDOC
+ The LINKAGE relocation outputs a linkage pair in the object file,
+ which is filled by the linker.
+
+ENUM
+ BFD_RELOC_ALPHA_CODEADDR
+ENUMDOC
+ The CODEADDR relocation outputs a STO_CA in the object file,
+ which is filled by the linker.
+
ENUM
BFD_RELOC_MIPS_JMP
ENUMDOC
Bits 27..2 of the relocation address shifted right 2 bits;
simple reloc otherwise.
+ENUM
+ BFD_RELOC_MIPS16_JMP
+ENUMDOC
+ The MIPS16 jump instruction.
+
+ENUM
+ BFD_RELOC_MIPS16_GPREL
+ENUMDOC
+ MIPS16 GP relative reloc.
+
ENUM
BFD_RELOC_HI16
ENUMDOC
ENUMEQX
BFD_RELOC_MIPS_GPREL32
BFD_RELOC_GPREL32
+ENUMX
+ BFD_RELOC_MIPS_GOT_HI16
+ENUMX
+ BFD_RELOC_MIPS_GOT_LO16
+ENUMX
+ BFD_RELOC_MIPS_CALL_HI16
+ENUMX
+ BFD_RELOC_MIPS_CALL_LO16
+COMMENT
+{* start-sanitize-r5900 *}
+ENUMX
+ BFD_RELOC_MIPS15_S3
+COMMENT
+{* end-sanitize-r5900 *}
ENUMDOC
MIPS ELF relocations.
+COMMENT
+{* start-sanitize-sky *}
+ENUM
+ BFD_RELOC_MIPS_DVP_11_PCREL
+ENUMDOC
+ MIPS DVP Relocations.
+ This is an 11-bit pc relative reloc. The recorded address is for the
+ lower instruction word, and the value is in 128 bit units.
+ENUM
+ BFD_RELOC_MIPS_DVP_27_S4
+ENUMDOC
+ This is a 27 bit address left shifted by 4.
+ENUM
+ BFD_RELOC_MIPS_DVP_11_S4
+ENUMDOC
+ This is the 11 bit offset operand of ilw/stw instructions
+ left shifted by 4.
+ENUM
+ BFD_RELOC_MIPS_DVP_U15_S3
+ENUMDOC
+ This is the 15 bit unsigned immediate operand of the iaddiu instruction
+ left shifted by 3.
+COMMENT
+{* end-sanitize-sky *}
+
ENUM
BFD_RELOC_386_GOT32
ENUMX
ENUM
BFD_RELOC_PPC_B26
-ENUMDOC
- PowerPC/POWER (RS/6000) relocs.
- 26 bit relative branch. Low two bits must be zero. High 24
- bits installed in bits 6 through 29 of instruction.
-ENUM
+ENUMX
BFD_RELOC_PPC_BA26
-ENUMDOC
- 26 bit absolute branch, like BFD_RELOC_PPC_B26 but absolute.
-ENUM
+ENUMX
BFD_RELOC_PPC_TOC16
+ENUMX
+ BFD_RELOC_PPC_B16
+ENUMX
+ BFD_RELOC_PPC_B16_BRTAKEN
+ENUMX
+ BFD_RELOC_PPC_B16_BRNTAKEN
+ENUMX
+ BFD_RELOC_PPC_BA16
+ENUMX
+ BFD_RELOC_PPC_BA16_BRTAKEN
+ENUMX
+ BFD_RELOC_PPC_BA16_BRNTAKEN
+ENUMX
+ BFD_RELOC_PPC_COPY
+ENUMX
+ BFD_RELOC_PPC_GLOB_DAT
+ENUMX
+ BFD_RELOC_PPC_JMP_SLOT
+ENUMX
+ BFD_RELOC_PPC_RELATIVE
+ENUMX
+ BFD_RELOC_PPC_LOCAL24PC
+ENUMX
+ BFD_RELOC_PPC_EMB_NADDR32
+ENUMX
+ BFD_RELOC_PPC_EMB_NADDR16
+ENUMX
+ BFD_RELOC_PPC_EMB_NADDR16_LO
+ENUMX
+ BFD_RELOC_PPC_EMB_NADDR16_HI
+ENUMX
+ BFD_RELOC_PPC_EMB_NADDR16_HA
+ENUMX
+ BFD_RELOC_PPC_EMB_SDAI16
+ENUMX
+ BFD_RELOC_PPC_EMB_SDA2I16
+ENUMX
+ BFD_RELOC_PPC_EMB_SDA2REL
+ENUMX
+ BFD_RELOC_PPC_EMB_SDA21
+ENUMX
+ BFD_RELOC_PPC_EMB_MRKREF
+ENUMX
+ BFD_RELOC_PPC_EMB_RELSEC16
+ENUMX
+ BFD_RELOC_PPC_EMB_RELST_LO
+ENUMX
+ BFD_RELOC_PPC_EMB_RELST_HI
+ENUMX
+ BFD_RELOC_PPC_EMB_RELST_HA
+ENUMX
+ BFD_RELOC_PPC_EMB_BIT_FLD
+ENUMX
+ BFD_RELOC_PPC_EMB_RELSDA
ENUMDOC
- 16 bit TOC relative reference.
+ Power(rs6000) and PowerPC relocations.
ENUM
BFD_RELOC_CTOR
probably a 32 bit wide absolute relocation, but the target can choose.
It generally does map to one of the other relocation types.
+ENUM
+ BFD_RELOC_ARM_PCREL_BRANCH
+ENUMDOC
+ ARM 26 bit pc-relative branch. The lowest two bits must be zero and are
+ not stored in the instruction.
+ENUM
+ BFD_RELOC_ARM_IMMEDIATE
+ENUMX
+ BFD_RELOC_ARM_OFFSET_IMM
+ENUMX
+ BFD_RELOC_ARM_SHIFT_IMM
+ENUMX
+ BFD_RELOC_ARM_SWI
+ENUMX
+ BFD_RELOC_ARM_MULTI
+ENUMX
+ BFD_RELOC_ARM_CP_OFF_IMM
+ENUMX
+ BFD_RELOC_ARM_ADR_IMM
+ENUMX
+ BFD_RELOC_ARM_LDR_IMM
+ENUMX
+ BFD_RELOC_ARM_LITERAL
+ENUMX
+ BFD_RELOC_ARM_IN_POOL
+ENUMX
+ BFD_RELOC_ARM_OFFSET_IMM8
+ENUMX
+ BFD_RELOC_ARM_HWLITERAL
+ENUMX
+ BFD_RELOC_ARM_THUMB_ADD
+ENUMX
+ BFD_RELOC_ARM_THUMB_IMM
+ENUMX
+ BFD_RELOC_ARM_THUMB_SHIFT
+ENUMX
+ BFD_RELOC_ARM_THUMB_OFFSET
+ENUMDOC
+ These relocs are only used within the ARM assembler. They are not
+ (at present) written to any object files.
+
+ENUM
+ BFD_RELOC_SH_PCDISP8BY2
+ENUMX
+ BFD_RELOC_SH_PCDISP12BY2
+ENUMX
+ BFD_RELOC_SH_IMM4
+ENUMX
+ BFD_RELOC_SH_IMM4BY2
+ENUMX
+ BFD_RELOC_SH_IMM4BY4
+ENUMX
+ BFD_RELOC_SH_IMM8
+ENUMX
+ BFD_RELOC_SH_IMM8BY2
+ENUMX
+ BFD_RELOC_SH_IMM8BY4
+ENUMX
+ BFD_RELOC_SH_PCRELIMM8BY2
+ENUMX
+ BFD_RELOC_SH_PCRELIMM8BY4
+ENUMX
+ BFD_RELOC_SH_SWITCH16
+ENUMX
+ BFD_RELOC_SH_SWITCH32
+ENUMX
+ BFD_RELOC_SH_USES
+ENUMX
+ BFD_RELOC_SH_COUNT
+ENUMX
+ BFD_RELOC_SH_ALIGN
+ENUMX
+ BFD_RELOC_SH_CODE
+ENUMX
+ BFD_RELOC_SH_DATA
+ENUMX
+ BFD_RELOC_SH_LABEL
+ENUMDOC
+ Hitachi SH relocs. Not all of these appear in object files.
+
+ENUM
+ BFD_RELOC_THUMB_PCREL_BRANCH9
+ENUMX
+ BFD_RELOC_THUMB_PCREL_BRANCH12
+ENUMX
+ BFD_RELOC_THUMB_PCREL_BRANCH23
+ENUMDOC
+ Thumb 23-, 12- and 9-bit pc-relative branches. The lowest bit must
+ be zero and is not stored in the instruction.
+
+ENUM
+ BFD_RELOC_ARC_B22_PCREL
+ENUMDOC
+ Argonaut RISC Core (ARC) relocs.
+ ARC 22 bit pc-relative branch. The lowest two bits must be zero and are
+ not stored in the instruction. The high 20 bits are installed in bits 26
+ through 7 of the instruction.
+ENUM
+ BFD_RELOC_ARC_B26
+ENUMDOC
+ ARC 26 bit absolute branch. The lowest two bits must be zero and are not
+ stored in the instruction. The high 24 bits are installed in bits 23
+ through 0.
+
+ENUM
+ BFD_RELOC_D10V_10_PCREL_R
+ENUMDOC
+ Mitsubishi D10V relocs.
+ This is a 10-bit reloc with the right 2 bits
+ assumed to be 0.
+ENUM
+ BFD_RELOC_D10V_10_PCREL_L
+ENUMDOC
+ Mitsubishi D10V relocs.
+ This is a 10-bit reloc with the right 2 bits
+ assumed to be 0. This is the same as the previous reloc
+ except it is in the left container, i.e.,
+ shifted left 15 bits.
+ENUM
+ BFD_RELOC_D10V_18
+ENUMDOC
+ This is an 18-bit reloc with the right 2 bits
+ assumed to be 0.
+ENUM
+ BFD_RELOC_D10V_18_PCREL
+ENUMDOC
+ This is an 18-bit reloc with the right 2 bits
+ assumed to be 0.
+
+ENUM
+ BFD_RELOC_D30V_6
+ENUMDOC
+ Mitsubishi D30V relocs.
+ This is a 6-bit absolute reloc.
+ENUM
+ BFD_RELOC_D30V_9_PCREL
+ENUMDOC
+ This is a 6-bit pc-relative reloc with
+ the right 3 bits assumed to be 0.
+ENUM
+ BFD_RELOC_D30V_9_PCREL_R
+ENUMDOC
+ This is a 6-bit pc-relative reloc with
+ the right 3 bits assumed to be 0. Same
+ as the previous reloc but on the right side
+ of the container.
+ENUM
+ BFD_RELOC_D30V_15
+ENUMDOC
+ This is a 12-bit absolute reloc with the
+ right 3 bitsassumed to be 0.
+ENUM
+ BFD_RELOC_D30V_15_PCREL
+ENUMDOC
+ This is a 12-bit pc-relative reloc with
+ the right 3 bits assumed to be 0.
+ENUM
+ BFD_RELOC_D30V_15_PCREL_R
+ENUMDOC
+ This is a 12-bit pc-relative reloc with
+ the right 3 bits assumed to be 0. Same
+ as the previous reloc but on the right side
+ of the container.
+ENUM
+ BFD_RELOC_D30V_21
+ENUMDOC
+ This is an 18-bit absolute reloc with
+ the right 3 bits assumed to be 0.
+ENUM
+ BFD_RELOC_D30V_21_PCREL
+ENUMDOC
+ This is an 18-bit pc-relative reloc with
+ the right 3 bits assumed to be 0.
+ENUM
+ BFD_RELOC_D30V_21_PCREL_R
+ENUMDOC
+ This is an 18-bit pc-relative reloc with
+ the right 3 bits assumed to be 0. Same
+ as the previous reloc but on the right side
+ of the container.
+ENUM
+ BFD_RELOC_D30V_32
+ENUMDOC
+ This is a 32-bit absolute reloc.
+ENUM
+ BFD_RELOC_D30V_32_PCREL
+ENUMDOC
+ This is a 32-bit pc-relative reloc.
+
+ENUM
+ BFD_RELOC_M32R_24
+ENUMDOC
+ Mitsubishi M32R relocs.
+ This is a 24 bit absolute address.
+ENUM
+ BFD_RELOC_M32R_10_PCREL
+ENUMDOC
+ This is a 10-bit pc-relative reloc with the right 2 bits assumed to be 0.
+ENUM
+ BFD_RELOC_M32R_18_PCREL
+ENUMDOC
+ This is an 18-bit reloc with the right 2 bits assumed to be 0.
+ENUM
+ BFD_RELOC_M32R_26_PCREL
+ENUMDOC
+ This is a 26-bit reloc with the right 2 bits assumed to be 0.
+ENUM
+ BFD_RELOC_M32R_HI16_ULO
+ENUMDOC
+ This is a 16-bit reloc containing the high 16 bits of an address
+ used when the lower 16 bits are treated as unsigned.
+ENUM
+ BFD_RELOC_M32R_HI16_SLO
+ENUMDOC
+ This is a 16-bit reloc containing the high 16 bits of an address
+ used when the lower 16 bits are treated as signed.
+ENUM
+ BFD_RELOC_M32R_LO16
+ENUMDOC
+ This is a 16-bit reloc containing the lower 16 bits of an address.
+ENUM
+ BFD_RELOC_M32R_SDA16
+ENUMDOC
+ This is a 16-bit reloc containing the small data area offset for use in
+ add3, load, and store instructions.
+
+ENUM
+ BFD_RELOC_V850_9_PCREL
+ENUMDOC
+ This is a 9-bit reloc
+ENUM
+ BFD_RELOC_V850_22_PCREL
+ENUMDOC
+ This is a 22-bit reloc
+
+ENUM
+ BFD_RELOC_V850_SDA_16_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the short data area pointer.
+ENUM
+ BFD_RELOC_V850_SDA_15_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset (of which only 15 bits are used) from the
+ short data area pointer.
+ENUM
+ BFD_RELOC_V850_ZDA_16_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the zero data area pointer.
+ENUM
+ BFD_RELOC_V850_ZDA_15_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset (of which only 15 bits are used) from the
+ zero data area pointer.
+ENUM
+ BFD_RELOC_V850_TDA_6_8_OFFSET
+ENUMDOC
+ This is an 8 bit offset (of which only 6 bits are used) from the
+ tiny data area pointer.
+ENUM
+ BFD_RELOC_V850_TDA_7_8_OFFSET
+ENUMDOC
+ This is an 8bit offset (of which only 7 bits are used) from the tiny
+ data area pointer.
+ENUM
+ BFD_RELOC_V850_TDA_7_7_OFFSET
+ENUMDOC
+ This is a 7 bit offset from the tiny data area pointer.
+ENUM
+ BFD_RELOC_V850_TDA_16_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the tiny data area pointer.
+COMMENT
+{* start-sanitize-v850e *}
+ENUM
+ BFD_RELOC_V850_TDA_4_5_OFFSET
+ENUMDOC
+ This is a 5 bit offset (of which only 4 bits are used) from the tiny
+ data area pointer.
+ENUM
+ BFD_RELOC_V850_TDA_4_4_OFFSET
+ENUMDOC
+ This is a 4 bit offset from the tiny data area pointer.
+ENUM
+ BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the short data area pointer, with the
+ bits placed non-contigously in the instruction.
+ENUM
+ BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the zero data area pointer, with the
+ bits placed non-contigously in the instruction.
+ENUM
+ BFD_RELOC_V850_CALLT_6_7_OFFSET
+ENUMDOC
+ This is a 6 bit offset from the call table base pointer.
+ENUM
+ BFD_RELOC_V850_CALLT_16_16_OFFSET
+ENUMDOC
+ This is a 16 bit offset from the call table base pointer.
+COMMENT
+{* end-sanitize-v850e *}
+
+ENUM
+ BFD_RELOC_MN10300_32_PCREL
+ENUMDOC
+ This is a 32bit pcrel reloc for the mn10300, offset by two bytes in the
+ instruction.
+ENUM
+ BFD_RELOC_MN10300_16_PCREL
+ENUMDOC
+ This is a 16bit pcrel reloc for the mn10300, offset by two bytes in the
+ instruction.
+
+ENUM
+ BFD_RELOC_TIC30_LDP
+ENUMDOC
+ This is a 8bit DP reloc for the tms320c30, where the most
+ significant 8 bits of a 24 bit word are placed into the least
+ significant 8 bits of the opcode.
+
+ENUM
+ BFD_RELOC_VTABLE_INHERIT
+ENUMX
+ BFD_RELOC_VTABLE_ENTRY
+ENUMDOC
+ These two relocations are used by the linker to determine which of
+ the entries in a C++ virtual function table are actually used. When
+ the --gc-sections option is given, the linker will zero out the entries
+ that are not used, so that the code for those functions need not be
+ included in the output.
+
+ VTABLE_INHERIT is a zero-space relocation used to describe to the
+ linker the inheritence tree of a C++ virtual function table. The
+ relocation's symbol should be the parent class' vtable, and the
+ relocation should be located at the child vtable.
+
+ VTABLE_ENTRY is a zero-space relocation that describes the use of a
+ virtual function table entry. The reloc's symbol should refer to the
+ table of the class mentioned in the code. Off of that base, an offset
+ describes the entry that is being used. For Rela hosts, this offset
+ is stored in the reloc's addend. For Rel hosts, we are forced to put
+ this offset in the reloc's section offset.
+
ENDSENUM
BFD_RELOC_UNUSED
-
CODE_FRAGMENT
.
.typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
bfd_reloc_type_lookup
SYNOPSIS
- const struct reloc_howto_struct *
+ reloc_howto_type *
bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code);
DESCRIPTION
*/
-const struct reloc_howto_struct *
+reloc_howto_type *
bfd_reloc_type_lookup (abfd, code)
bfd *abfd;
bfd_reloc_code_real_type code;
bfd_default_reloc_type_lookup
SYNOPSIS
- const struct reloc_howto_struct *bfd_default_reloc_type_lookup
+ reloc_howto_type *bfd_default_reloc_type_lookup
(bfd *abfd, bfd_reloc_code_real_type code);
DESCRIPTION
*/
-const struct reloc_howto_struct *
+reloc_howto_type *
bfd_default_reloc_type_lookup (abfd, code)
bfd *abfd;
bfd_reloc_code_real_type code;
default:
BFD_FAIL ();
}
- return (const struct reloc_howto_struct *) NULL;
+ return (reloc_howto_type *) NULL;
}
/*
return true;
}
+/*
+INTERNAL_FUNCTION
+ bfd_generic_gc_sections
+
+SYNOPSIS
+ boolean bfd_generic_gc_sections
+ (bfd *, struct bfd_link_info *);
+
+DESCRIPTION
+ Provides default handling for relaxing for back ends which
+ don't do section gc -- i.e., does nothing.
+*/
+
+/*ARGSUSED*/
+boolean
+bfd_generic_gc_sections (abfd, link_info)
+ bfd *abfd;
+ struct bfd_link_info *link_info;
+{
+ return true;
+}
+
/*
INTERNAL_FUNCTION
bfd_generic_get_relocated_section_contents
if (reloc_size < 0)
goto error_return;
- reloc_vector = (arelent **) malloc (reloc_size);
+ reloc_vector = (arelent **) bfd_malloc ((size_t) reloc_size);
if (reloc_vector == NULL && reloc_size != 0)
- {
- bfd_set_error (bfd_error_no_memory);
- goto error_return;
- }
+ goto error_return;
/* read in the section */
if (!bfd_get_section_contents (input_bfd,
projects / deliverable / binutils-gdb.git / blobdiff