Fix typos in comments, and restore comment formatting destroyed by emacs at

some stage.
This commit is contained in:
Alan Modra
2000-03-11 01:16:52 +00:00
parent fb5577443e
commit 88b6bae086
2 changed files with 56 additions and 47 deletions

View File

@ -1,3 +1,12 @@
2000-03-10 Alan Modra <alan@spri.levels.unisa.edu.au>
* reloc.c (bfd_perform_relocation): Undo emacs formatting of
comment, and ensure it doesn't happen again.
(bfd_install_relocation): Same here.
(_bfd_relocate_contents): Don't bother assigning unused signmask
shift result. Fix typos in comments.
Remove trailing whitespace throughout file.
2000-03-07 Doug Evans <dje@casey.transmeta.com> 2000-03-07 Doug Evans <dje@casey.transmeta.com>
* reloc.c (reloc_howto_struct): Fix partial_inplace comment. * reloc.c (reloc_howto_struct): Fix partial_inplace comment.

View File

@ -25,7 +25,7 @@ SECTION
BFD maintains relocations in much the same way it maintains BFD maintains relocations in much the same way it maintains
symbols: they are left alone until required, then read in symbols: they are left alone until required, then read in
en-mass and translated into an internal form. A common en-masse and translated into an internal form. A common
routine <<bfd_perform_relocation>> acts upon the routine <<bfd_perform_relocation>> acts upon the
canonical form to do the fixup. canonical form to do the fixup.
@ -359,7 +359,7 @@ CODE_FRAGMENT
. .
. {* The src_mask selects which parts of the read in data . {* 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 . are to be used in the relocation sum. E.g., if this was an 8 bit
. bit of data which we read and relocated, this would be . byte of data which we read and relocated, this would be
. 0x000000ff. When we have relocs which have an addend, such as . 0x000000ff. When we have relocs which have an addend, such as
. sun4 extended relocs, the value in the offset part of a . sun4 extended relocs, the value in the offset part of a
. relocating field is garbage so we never use it. In this case . relocating field is garbage so we never use it. In this case
@ -885,23 +885,23 @@ space consuming. For each target:
R result R result
Do this: Do this:
i i i i i o o o o o from bfd_get<size> (( 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 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 + 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 and D D D D D to chop to right size
----------------------- -----------------------
A A A A A = A A A A A
And this: And this:
... i i i i i o o o o o from bfd_get<size> ( i i i i i o o o o o from bfd_get<size>
and N N N N N get instruction and N N N N N ) get instruction
----------------------- -----------------------
... B B B B B = B B B B B
And then: And then:
B B B B B ( B B B B B
or A A A A A or A A A A A)
----------------------- -----------------------
R R R R R R R R R R put into bfd_put<size> = R R R R R R R R R R put into bfd_put<size>
*/ */
#define DOIT(x) \ #define DOIT(x) \
@ -1028,7 +1028,7 @@ bfd_install_relocation (abfd, reloc_entry, data_start, data_start_offset,
if (howto->special_function) if (howto->special_function)
{ {
bfd_reloc_status_type cont; bfd_reloc_status_type cont;
/* XXX - The special_function calls haven't been fixed up to deal /* XXX - The special_function calls haven't been fixed up to deal
with creating new relocations and section contents. */ with creating new relocations and section contents. */
cont = howto->special_function (abfd, reloc_entry, symbol, cont = howto->special_function (abfd, reloc_entry, symbol,
@ -1275,23 +1275,23 @@ space consuming. For each target:
R result R result
Do this: Do this:
i i i i i o o o o o from bfd_get<size> (( 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 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 + 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 and D D D D D to chop to right size
----------------------- -----------------------
A A A A A = A A A A A
And this: And this:
... i i i i i o o o o o from bfd_get<size> ( i i i i i o o o o o from bfd_get<size>
and N N N N N get instruction and N N N N N ) get instruction
----------------------- -----------------------
... B B B B B = B B B B B
And then: And then:
B B B B B ( B B B B B
or A A A A A or A A A A A)
----------------------- -----------------------
R R R R R R R R R R put into bfd_put<size> = R R R R R R R R R R put into bfd_put<size>
*/ */
#define DOIT(x) \ #define DOIT(x) \
@ -1504,7 +1504,7 @@ _bfd_relocate_contents (howto, input_bfd, relocation, location)
if ((b & signmask) != 0) if ((b & signmask) != 0)
{ {
/* Set all the bits above the sign bit. */ /* Set all the bits above the sign bit. */
b -= signmask <<= 1; b -= signmask << 1;
} }
b = (b & addrmask) >> bitpos; b = (b & addrmask) >> bitpos;
@ -1560,7 +1560,7 @@ _bfd_relocate_contents (howto, input_bfd, relocation, location)
If the field is signed and a is -4095 (0x1001) and b is If the field is signed and a is -4095 (0x1001) and b is
-1 (0x1fff), the sum is -4096 (0x1000), but (0x1001 + -1 (0x1fff), the sum is -4096 (0x1000), but (0x1001 +
0x1fff is 0x3000). It's not clear how to handle this 0x1fff is 0x3000). It's not clear how to handle this
everywhere, since there is not way to know how many bits everywhere, since there is no way to know how many bits
are significant in the relocation, but the original code are significant in the relocation, but the original code
assumed that it was fully sign extended, and we will keep assumed that it was fully sign extended, and we will keep
that assumption. */ that assumption. */
@ -1570,7 +1570,7 @@ _bfd_relocate_contents (howto, input_bfd, relocation, location)
{ {
/* Some bits out of the field are set. This might not /* Some bits out of the field are set. This might not
be a problem: if this is a signed bitfield, it is OK be a problem: if this is a signed bitfield, it is OK
iff all the high bits are set, including the sign if all the high bits are set, including the sign
bit. We'll try setting all but the most significant bit. We'll try setting all but the most significant
bit in the original relocation value: if this is all bit in the original relocation value: if this is all
ones, we are OK, assuming a signed bitfield. */ ones, we are OK, assuming a signed bitfield. */
@ -1594,9 +1594,9 @@ _bfd_relocate_contents (howto, input_bfd, relocation, location)
sum = a + b; sum = a + b;
if (sum < a || (sum & ~ fieldmask) != 0) if (sum < a || (sum & ~ fieldmask) != 0)
{ {
/* There was a carry out, or the field overflow. Test /* There was a carry out, or the field overflowed. Test
for signed operands again. Here is the overflow test for signed operands again. Here the overflow test is
is as for complain_overflow_signed. */ as for complain_overflow_signed. */
if (((~ (a ^ b)) & (a ^ sum)) & signmask) if (((~ (a ^ b)) & (a ^ sum)) & signmask)
overflow = true; overflow = true;
} }
@ -2152,7 +2152,7 @@ ENUMX
BFD_RELOC_PJ_CODE_REL32 BFD_RELOC_PJ_CODE_REL32
ENUMDOC ENUMDOC
Picojava relocs. Not all of these appear in object files. Picojava relocs. Not all of these appear in object files.
ENUM ENUM
BFD_RELOC_PPC_B26 BFD_RELOC_PPC_B26
ENUMX ENUMX
@ -2385,46 +2385,46 @@ ENUMDOC
ENUM ENUM
BFD_RELOC_D30V_9_PCREL BFD_RELOC_D30V_9_PCREL
ENUMDOC ENUMDOC
This is a 6-bit pc-relative reloc with This is a 6-bit pc-relative reloc with
the right 3 bits assumed to be 0. the right 3 bits assumed to be 0.
ENUM ENUM
BFD_RELOC_D30V_9_PCREL_R BFD_RELOC_D30V_9_PCREL_R
ENUMDOC ENUMDOC
This is a 6-bit pc-relative reloc with This is a 6-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side as the previous reloc but on the right side
of the container. of the container.
ENUM ENUM
BFD_RELOC_D30V_15 BFD_RELOC_D30V_15
ENUMDOC ENUMDOC
This is a 12-bit absolute reloc with the This is a 12-bit absolute reloc with the
right 3 bitsassumed to be 0. right 3 bitsassumed to be 0.
ENUM ENUM
BFD_RELOC_D30V_15_PCREL BFD_RELOC_D30V_15_PCREL
ENUMDOC ENUMDOC
This is a 12-bit pc-relative reloc with This is a 12-bit pc-relative reloc with
the right 3 bits assumed to be 0. the right 3 bits assumed to be 0.
ENUM ENUM
BFD_RELOC_D30V_15_PCREL_R BFD_RELOC_D30V_15_PCREL_R
ENUMDOC ENUMDOC
This is a 12-bit pc-relative reloc with This is a 12-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side as the previous reloc but on the right side
of the container. of the container.
ENUM ENUM
BFD_RELOC_D30V_21 BFD_RELOC_D30V_21
ENUMDOC ENUMDOC
This is an 18-bit absolute reloc with This is an 18-bit absolute reloc with
the right 3 bits assumed to be 0. the right 3 bits assumed to be 0.
ENUM ENUM
BFD_RELOC_D30V_21_PCREL BFD_RELOC_D30V_21_PCREL
ENUMDOC ENUMDOC
This is an 18-bit pc-relative reloc with This is an 18-bit pc-relative reloc with
the right 3 bits assumed to be 0. the right 3 bits assumed to be 0.
ENUM ENUM
BFD_RELOC_D30V_21_PCREL_R BFD_RELOC_D30V_21_PCREL_R
ENUMDOC ENUMDOC
This is an 18-bit pc-relative reloc with This is an 18-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side as the previous reloc but on the right side
of the container. of the container.
@ -2606,7 +2606,7 @@ ENUM
ENUMDOC ENUMDOC
This is a 16 bit reloc for the FR30 that stores a 12 bit pc relative This is a 16 bit reloc for the FR30 that stores a 12 bit pc relative
short offset into 11 bits. short offset into 11 bits.
ENUM ENUM
BFD_RELOC_MCORE_PCREL_IMM8BY4 BFD_RELOC_MCORE_PCREL_IMM8BY4
ENUMX ENUMX
@ -2621,13 +2621,13 @@ ENUMX
BFD_RELOC_MCORE_RVA BFD_RELOC_MCORE_RVA
ENUMDOC ENUMDOC
Motorola Mcore relocations. Motorola Mcore relocations.
ENUM ENUM
BFD_RELOC_VTABLE_INHERIT BFD_RELOC_VTABLE_INHERIT
ENUMX ENUMX
BFD_RELOC_VTABLE_ENTRY BFD_RELOC_VTABLE_ENTRY
ENUMDOC ENUMDOC
These two relocations are used by the linker to determine which of 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 entries in a C++ virtual function table are actually used. When
the --gc-sections option is given, the linker will zero out the entries 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 that are not used, so that the code for those functions need not be
@ -2641,7 +2641,7 @@ ENUMDOC
VTABLE_ENTRY is a zero-space relocation that describes the use of a 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 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 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 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 is stored in the reloc's addend. For Rel hosts, we are forced to put
this offset in the reloc's section offset. this offset in the reloc's section offset.