OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

* bfd/reloc.c (struct reloc_howto_struct): Revise src_mask and 

dst_mask comments.
	* bfd-in2.h: Regenerate.
This commit is contained in:
Alan Modra 2002-12-18 13:47:03 +00:00
parent 47388f4cc3
commit 7dc77aaa7d
3 changed files with 26 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
bfd/ChangeLog
View File

@ -1,3 +1,9 @@
2002-12-19 Alan Modra <amodra@bigpond.net.au>
* bfd/reloc.c (struct reloc_howto_struct): Revise src_mask and
dst_mask comments.
* bfd-in2.h: Regenerate.
2002-12-18 Alan Modra <amodra@bigpond.net.au>
* elf32-ppc.c (ppc_elf_relocate_section): Reorganize dynamic reloc

21
bfd/bfd-in2.h
View File

@ -1920,19 +1920,18 @@ struct reloc_howto_struct
links (e.g. GOT stuff) it doesn't matter what this is set to. */
bfd_boolean partial_inplace;
/* The src_mask selects which parts of the read in data
are to be used in the relocation sum. E.g., if this was an 8 bit
byte of data which we read and relocated, this would be
0x000000ff. When we have relocs which have an addend, such as
sun4 extended relocs, the value in the offset part of a
relocating field is garbage so we never use it. In this case
the mask would be 0x00000000. */
/* src_mask selects the part of the instruction (or data) to be used
in the relocation sum. If the target relocations don't have an
addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
dst_mask to extract the addend from the section contents. If
relocations do have an addend in the reloc, eg. ELF USE_RELA, this
field should be zero. Non-zero values for ELF USE_RELA targets are
bogus as in those cases the value in the dst_mask part of the
section contents should be treated as garbage. */
bfd_vma src_mask;
/* The dst_mask selects which parts of the instruction are replaced
into the instruction. In most cases src_mask == dst_mask,
except in the above special case, where dst_mask would be
0x000000ff, and src_mask would be 0x00000000. */
/* dst_mask selects which parts of the instruction (or data) are
replaced with a relocated value. */
bfd_vma dst_mask;
/* When some formats create PC relative instructions, they leave

21
bfd/reloc.c
View File

@ -344,19 +344,18 @@ CODE_FRAGMENT
. links (e.g. GOT stuff) it doesn't matter what this is set to. *}
. bfd_boolean partial_inplace;
.
. {* The src_mask selects which parts of the read in data
. are to be used in the relocation sum. E.g., if this was an 8 bit
. byte of data which we read and relocated, this would be
. 0x000000ff. When we have relocs which have an addend, such as
. sun4 extended relocs, the value in the offset part of a
. relocating field is garbage so we never use it. In this case
. the mask would be 0x00000000. *}
. {* src_mask selects the part of the instruction (or data) to be used
. in the relocation sum. If the target relocations don't have an
. addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
. dst_mask to extract the addend from the section contents. If
. relocations do have an addend in the reloc, eg. ELF USE_RELA, this
. field should be zero. Non-zero values for ELF USE_RELA targets are
. bogus as in those cases the value in the dst_mask part of the
. section contents should be treated as garbage. *}
. bfd_vma src_mask;
.
. {* The dst_mask selects which parts of the instruction are replaced
. into the instruction. In most cases src_mask == dst_mask,
. except in the above special case, where dst_mask would be
. 0x000000ff, and src_mask would be 0x00000000. *}
. {* dst_mask selects which parts of the instruction (or data) are
. replaced with a relocated value. *}
. bfd_vma dst_mask;
.
. {* When some formats create PC relative instructions, they leave