/*
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.
-
-
-
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>>
| return foo[0x12345678];
| }
- Could be compiled into:
+ Could be compiled into:
| linkw fp,#-4
| moveb @@#12345678,d0
| 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
|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
|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
| 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
|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.
*/
/*
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. *}
.#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
.#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; \
+. } \
+. } \
. }
.
*/
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 */
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}.
*/
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
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) \
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
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) \
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))
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;
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
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;
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
projects / deliverable / binutils-gdb.git / blobdiff