Mon Oct 14 11:17:24 1996 Richard Henderson <rth@tamu.edu>

* reloc.c: Create a new BFD_RELOC_ALPHA_ELF_LITERAL.  It was a
	mistake to have reused the ECOFF LITERAL for ELF since they have
	different semantics.
	* elf64-alpha.c (elf_reloc_map): Map from ELF_LITERAL.
	* bfd-in2.h, libbfd.h: Rebuild.

	* elf64-alpha.c (elf64_alpha_size_dynamic_sections): Trap .got
	section overflow.

	* elf64-alpha.c (elf64_alpha_relocate_section): Do not emit a
	dynamic relocation for an undefweak symbol when we are building
	a static executable.
This commit is contained in:
Ian Lance Taylor
1996-10-14 15:21:54 +00:00
parent 19406903ab
commit 6b31fd3af3
4 changed files with 56 additions and 13 deletions

View File

@ -1,3 +1,18 @@
Mon Oct 14 11:17:24 1996 Richard Henderson <rth@tamu.edu>
* reloc.c: Create a new BFD_RELOC_ALPHA_ELF_LITERAL. It was a
mistake to have reused the ECOFF LITERAL for ELF since they have
different semantics.
* elf64-alpha.c (elf_reloc_map): Map from ELF_LITERAL.
* bfd-in2.h, libbfd.h: Rebuild.
* elf64-alpha.c (elf64_alpha_size_dynamic_sections): Trap .got
section overflow.
* elf64-alpha.c (elf64_alpha_relocate_section): Do not emit a
dynamic relocation for an undefweak symbol when we are building
a static executable.
Thu Oct 10 11:15:06 1996 Stan Shebs <shebs@andros.cygnus.com>
* mpw-make.sed (config.bfd, targmatch.sed): Edit references to

View File

@ -1635,6 +1635,12 @@ section symbol. The addend is ignored when writing, but is filled
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
@ -1646,6 +1652,7 @@ of instruction using the register:
The GNU linker currently doesn't do any of this optimizing. */
BFD_RELOC_ALPHA_LITERAL,
BFD_RELOC_ALPHA_ELF_LITERAL,
BFD_RELOC_ALPHA_LITUSE,
/* The HINT relocation indicates a value that should be filled into the

View File

@ -631,6 +631,7 @@ static const char *const bfd_reloc_code_real_names[] = { "@@uninitialized@@",
"BFD_RELOC_ALPHA_GPDISP_LO16",
"BFD_RELOC_ALPHA_GPDISP",
"BFD_RELOC_ALPHA_LITERAL",
"BFD_RELOC_ALPHA_ELF_LITERAL",
"BFD_RELOC_ALPHA_LITUSE",
"BFD_RELOC_ALPHA_HINT",
"BFD_RELOC_ALPHA_LINKAGE",
@ -745,6 +746,18 @@ static const char *const bfd_reloc_code_real_names[] = { "@@uninitialized@@",
"BFD_RELOC_D10V_18_PCREL",
/* end-sanitize-d10v */
/* start-sanitize-m32r */
"BFD_RELOC_M32R_UIMM24",
"BFD_RELOC_M32R_DISP8",
"BFD_RELOC_M32R_DISP16",
"BFD_RELOC_M32R_DISP24",
/* end-sanitize-m32r */
/* start-sanitize-v850 */
"BFD_RELOC_V850_9_PCREL",
"BFD_RELOC_V850_22_PCREL",
/* end-sanitize-v850 */
"@@overflow: BFD_RELOC_UNUSED@@",
};
#endif

View File

@ -138,7 +138,7 @@ DESCRIPTION
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 (!)
@ -1073,12 +1073,12 @@ bfd_install_relocation (abfd, reloc_entry, data_start, data_start_offset,
{
/* 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
@ -1090,10 +1090,10 @@ bfd_install_relocation (abfd, reloc_entry, data_start, data_start_offset,
/* 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
@ -1903,6 +1903,8 @@ ENUMDOC
ENUM
BFD_RELOC_ALPHA_LITERAL
ENUMX
BFD_RELOC_ALPHA_ELF_LITERAL
ENUMX
BFD_RELOC_ALPHA_LITUSE
ENUMDOC
@ -1915,6 +1917,12 @@ 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
@ -2244,22 +2252,22 @@ COMMENT
COMMENT
{* start-sanitize-m32r *}
ENUM
BFD_RELOC_M32R_10_PCREL
BFD_RELOC_M32R_UIMM24
ENUMDOC
Mitsubishi M32R relocs.
This is a 24 bit address.
ENUM
BFD_RELOC_M32R_DISP8
ENUMDOC
This is a 10-bit reloc with the right 2 bits assumed to be 0.
ENUM
BFD_RELOC_M32R_18_PCREL
BFD_RELOC_M32R_DISP16
ENUMDOC
This is an 18-bit reloc with the right 2 bits assumed to be 0.
ENUM
BFD_RELOC_M32R_26_PCREL
BFD_RELOC_M32R_DISP24
ENUMDOC
This is an 26-bit reloc with the right 2 bits assumed to be 0.
ENUM
BFD_RELOC_M32R_24
ENUMDOC
This is a 24 bit reloc.
COMMENT
{* end-sanitize-m32r *}