diff options
Diffstat (limited to 'bfd/reloc.c')
| -rw-r--r-- | bfd/reloc.c | 272 |
1 files changed, 136 insertions, 136 deletions
diff --git a/bfd/reloc.c b/bfd/reloc.c index 0fe93be..4727f19 100644 --- a/bfd/reloc.c +++ b/bfd/reloc.c @@ -118,31 +118,31 @@ CODE_FRAGMENT /* DESCRIPTION - Here is a description of each of the fields within an <<arelent>>: - - o <<sym_ptr_ptr>> - - The symbol table pointer points to a pointer to the symbol - associated with the relocation request. It is the pointer - into the table returned by the back end's - <<canonicalize_symtab>> action. @xref{Symbols}. The symbol is - referenced through a pointer to a pointer so that tools like - the linker can fix up all the symbols of the same name by - modifying only one pointer. The relocation routine looks in - the symbol and uses the base of the section the symbol is - attached to and the value of the symbol as the initial - relocation offset. If the symbol pointer is zero, then the - section provided is looked up. - - o <<address>> - - The <<address>> field gives the offset in bytes from the base of - the section data which owns the relocation record to the first - byte of relocatable information. The actual data relocated - will be relative to this point; for example, a relocation - 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. + Here is a description of each of the fields within an <<arelent>>: + + o <<sym_ptr_ptr>> + + The symbol table pointer points to a pointer to the symbol + associated with the relocation request. It is the pointer + into the table returned by the back end's + <<canonicalize_symtab>> action. @xref{Symbols}. The symbol is + referenced through a pointer to a pointer so that tools like + the linker can fix up all the symbols of the same name by + modifying only one pointer. The relocation routine looks in + the symbol and uses the base of the section the symbol is + attached to and the value of the symbol as the initial + relocation offset. If the symbol pointer is zero, then the + section provided is looked up. + + o <<address>> + + The <<address>> field gives the offset in bytes from the base of + the section data which owns the relocation record to the first + byte of relocatable information. The actual data relocated + will be relative to this point; for example, a relocation + 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>> @@ -156,7 +156,7 @@ DESCRIPTION | return foo[0x12345678]; | } - Could be compiled into: + Could be compiled into: | linkw fp,#-4 | moveb @@#12345678,d0 @@ -164,8 +164,8 @@ DESCRIPTION | unlk fp | rts - This could create a reloc pointing to <<foo>>, but leave the - offset in the data, something like: + This could create a reloc pointing to <<foo>>, but leave the + offset in the data, something like: |RELOCATION RECORDS FOR [.text]: |offset type value @@ -177,16 +177,16 @@ DESCRIPTION |0000000c 4e5e ; unlk fp |0000000e 4e75 ; rts - Using coff and an 88k, some instructions don't have enough - space in them to represent the full address range, and - pointers have to be loaded in two parts. So you'd get something like: + Using coff and an 88k, some instructions don't have enough + space in them to represent the full address range, and + pointers have to be loaded in two parts. So you'd get something like: | or.u r13,r0,hi16(_foo+0x12345678) | ld.b r2,r13,lo16(_foo+0x12345678) | jmp r1 - This should create two relocs, both pointing to <<_foo>>, and with - 0x12340000 in their addend field. The data would consist of: + This should create two relocs, both pointing to <<_foo>>, and with + 0x12340000 in their addend field. The data would consist of: |RELOCATION RECORDS FOR [.text]: |offset type value @@ -197,18 +197,18 @@ DESCRIPTION |00000004 1c4d5678 ; ld.b r2,r13,0x5678 |00000008 f400c001 ; jmp r1 - The relocation routine digs out the value from the data, adds - it to the addend to get the original offset, and then adds the - value of <<_foo>>. Note that all 32 bits have to be kept around - somewhere, to cope with carry from bit 15 to bit 16. + The relocation routine digs out the value from the data, adds + it to the addend to get the original offset, and then adds the + value of <<_foo>>. Note that all 32 bits have to be kept around + somewhere, to cope with carry from bit 15 to bit 16. - One further example is the sparc and the a.out format. The - sparc has a similar problem to the 88k, in that some - instructions don't have room for an entire offset, but on the - sparc the parts are created in odd sized lumps. The designers of - the a.out format chose to not use the data within the section - for storing part of the offset; all the offset is kept within - the reloc. Anything in the data should be ignored. + One further example is the sparc and the a.out format. The + sparc has a similar problem to the 88k, in that some + instructions don't have room for an entire offset, but on the + sparc the parts are created in odd sized lumps. The designers of + the a.out format chose to not use the data within the section + for storing part of the offset; all the offset is kept within + the reloc. Anything in the data should be ignored. | save %sp,-112,%sp | sethi %hi(_foo+0x12345678),%g2 @@ -216,8 +216,8 @@ DESCRIPTION | ret | restore - Both relocs contain a pointer to <<foo>>, and the offsets - contain junk. + Both relocs contain a pointer to <<foo>>, and the offsets + contain junk. |RELOCATION RECORDS FOR [.text]: |offset type value @@ -230,15 +230,15 @@ DESCRIPTION |0000000c 81c7e008 ; ret |00000010 81e80000 ; restore - o <<howto>> + o <<howto>> - The <<howto>> field can be imagined as a - relocation instruction. It is a pointer to a structure which - contains information on what to do with all of the other - information in the reloc record and data section. A back end - would normally have a relocation instruction set and turn - relocations into pointers to the correct structure on input - - but it would be possible to create each howto field on demand. + The <<howto>> field can be imagined as a + relocation instruction. It is a pointer to a structure which + contains information on what to do with all of the other + information in the reloc record and data section. A back end + would normally have a relocation instruction set and turn + relocations into pointers to the correct structure on input - + but it would be possible to create each howto field on demand. */ @@ -274,10 +274,10 @@ CODE_FRAGMENT /* SUBSUBSECTION - <<reloc_howto_type>> + <<reloc_howto_type>> - The <<reloc_howto_type>> is a structure which contains all the - information that libbfd needs to know to tie up a back end's data. + The <<reloc_howto_type>> is a structure which contains all the + information that libbfd needs to know to tie up a back end's data. CODE_FRAGMENT .struct bfd_symbol; {* Forward declaration. *} @@ -385,7 +385,7 @@ DESCRIPTION .#define NEWHOWTO(FUNCTION, NAME, SIZE, REL, IN) \ . HOWTO (0, 0, SIZE, 0, REL, 0, complain_overflow_dont, FUNCTION, \ -. NAME, FALSE, 0, 0, IN) +. NAME, FALSE, 0, 0, IN) . DESCRIPTION @@ -393,25 +393,25 @@ DESCRIPTION .#define EMPTY_HOWTO(C) \ . HOWTO ((C), 0, 0, 0, FALSE, 0, complain_overflow_dont, NULL, \ -. NULL, FALSE, 0, 0, FALSE) +. NULL, FALSE, 0, 0, FALSE) . DESCRIPTION Helper routine to turn a symbol into a relocation value. -.#define HOWTO_PREPARE(relocation, symbol) \ -. { \ -. if (symbol != NULL) \ -. { \ -. if (bfd_is_com_section (symbol->section)) \ -. { \ -. relocation = 0; \ -. } \ -. else \ -. { \ -. relocation = symbol->value; \ -. } \ -. } \ +.#define HOWTO_PREPARE(relocation, symbol) \ +. { \ +. if (symbol != NULL) \ +. { \ +. if (bfd_is_com_section (symbol->section)) \ +. { \ +. relocation = 0; \ +. } \ +. else \ +. { \ +. relocation = symbol->value; \ +. } \ +. } \ . } . */ @@ -512,7 +512,7 @@ bfd_check_overflow (enum complain_overflow how, case complain_overflow_signed: /* If any sign bits are set, all sign bits must be set. That - is, A must be a valid negative address after shifting. */ + is, A must be a valid negative address after shifting. */ signmask = ~ (fieldmask >> 1); /* Fall thru */ @@ -546,13 +546,13 @@ FUNCTION SYNOPSIS bfd_boolean bfd_reloc_offset_in_range - (reloc_howto_type *howto, - bfd *abfd, - asection *section, - bfd_size_type offset); + (reloc_howto_type *howto, + bfd *abfd, + asection *section, + bfd_size_type offset); DESCRIPTION - Returns TRUE if the reloc described by @var{HOWTO} can be + Returns TRUE if the reloc described by @var{HOWTO} can be applied at @var{OFFSET} octets in @var{SECTION}. */ @@ -581,11 +581,11 @@ FUNCTION SYNOPSIS bfd_reloc_status_type bfd_perform_relocation - (bfd *abfd, - arelent *reloc_entry, - void *data, - asection *input_section, - bfd *output_bfd, + (bfd *abfd, + arelent *reloc_entry, + void *data, + asection *input_section, + bfd *output_bfd, char **error_message); DESCRIPTION @@ -895,23 +895,23 @@ space consuming. For each target: 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 + (( 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 + = 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 + ( 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 + = B B B B B And then: - ( B B B B B - or A A A A A) + ( 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> + = R R R R R R R R R R put into bfd_put<size> */ #define DOIT(x) \ @@ -987,10 +987,10 @@ FUNCTION SYNOPSIS bfd_reloc_status_type bfd_install_relocation - (bfd *abfd, - arelent *reloc_entry, - void *data, bfd_vma data_start, - asection *input_section, + (bfd *abfd, + arelent *reloc_entry, + void *data, bfd_vma data_start, + asection *input_section, char **error_message); DESCRIPTION @@ -1283,23 +1283,23 @@ space consuming. For each target: 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 + (( 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 + = 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 + ( 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 + = B B B B B And then: - ( B B B B B - or A A A A A) + ( 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> + = R R R R R R R R R R put into bfd_put<size> */ #define DOIT(x) \ @@ -1481,9 +1481,9 @@ _bfd_relocate_contents (reloc_howto_type *howto, bfd_vma a, b, sum; /* Get the values to be added together. For signed and unsigned - relocations, we assume that all values should be truncated to - the size of an address. For bitfields, all the bits matter. - See also bfd_check_overflow. */ + relocations, we assume that all values should be truncated to + the size of an address. For bitfields, all the bits matter. + See also bfd_check_overflow. */ fieldmask = N_ONES (howto->bitsize); signmask = ~fieldmask; addrmask = (N_ONES (bfd_arch_bits_per_address (input_bfd)) @@ -1512,11 +1512,11 @@ _bfd_relocate_contents (reloc_howto_type *howto, flag = bfd_reloc_overflow; /* We only need this next bit of code if the sign bit of B - is below the sign bit of A. This would only happen if - SRC_MASK had fewer bits than BITSIZE. Note that if - SRC_MASK has more bits than BITSIZE, we can get into - trouble; we would need to verify that B is in range, as - we do for A above. */ + is below the sign bit of A. This would only happen if + SRC_MASK had fewer bits than BITSIZE. Note that if + SRC_MASK has more bits than BITSIZE, we can get into + trouble; we would need to verify that B is in range, as + we do for A above. */ ss = ((~howto->src_mask) >> 1) & howto->src_mask; ss >>= bitpos; @@ -1527,12 +1527,12 @@ _bfd_relocate_contents (reloc_howto_type *howto, sum = a + b; /* See if the result has the correct sign. Bits above the - sign bit are junk now; ignore them. If the sum is - positive, make sure we did not have all negative inputs; - if the sum is negative, make sure we did not have all - positive inputs. The test below looks only at the sign - bits, and it really just - SIGN (A) == SIGN (B) && SIGN (A) != SIGN (SUM) + sign bit are junk now; ignore them. If the sum is + positive, make sure we did not have all negative inputs; + if the sum is negative, make sure we did not have all + positive inputs. The test below looks only at the sign + bits, and it really just + SIGN (A) == SIGN (B) && SIGN (A) != SIGN (SUM) We mask with addrmask here to explicitly allow an address wrap-around. The Linux kernel relies on it, and it is @@ -1545,16 +1545,16 @@ _bfd_relocate_contents (reloc_howto_type *howto, case complain_overflow_unsigned: /* Checking for an unsigned overflow is relatively easy: - trim the addresses and add, and trim the result as well. - Overflow is normally indicated when the result does not - fit in the field. However, we also need to consider the - case when, e.g., fieldmask is 0x7fffffff or smaller, an - input is 0x80000000, and bfd_vma is only 32 bits; then we - will get sum == 0, but there is an overflow, since the - inputs did not fit in the field. Instead of doing a - separate test, we can check for this by or-ing in the - operands when testing for the sum overflowing its final - field. */ + trim the addresses and add, and trim the result as well. + Overflow is normally indicated when the result does not + fit in the field. However, we also need to consider the + case when, e.g., fieldmask is 0x7fffffff or smaller, an + input is 0x80000000, and bfd_vma is only 32 bits; then we + will get sum == 0, but there is an overflow, since the + inputs did not fit in the field. Instead of doing a + separate test, we can check for this by or-ing in the + operands when testing for the sum overflowing its final + field. */ sum = (a + b) & addrmask; if ((a | b | sum) & signmask) flag = bfd_reloc_overflow; @@ -2155,9 +2155,9 @@ ENUMDOC away some literal section references. The symbol is ignored (read as the absolute section symbol), and the "addend" indicates the type of instruction using the register: - 1 - "memory" fmt insn - 2 - byte-manipulation (byte offset reg) - 3 - jsr (target of branch) + 1 - "memory" fmt insn + 2 - byte-manipulation (byte offset reg) + 3 - jsr (target of branch) ENUM BFD_RELOC_ALPHA_HINT |