[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
typedef enum bfd_reloc_status { /* No errors detected. */ bfd_reloc_ok, /* The relocation was performed, but there was an overflow. */ bfd_reloc_overflow, /* The address to relocate was not within the section supplied. */ bfd_reloc_outofrange, /* Used by special functions. */ bfd_reloc_continue, /* Unsupported relocation size requested. */ bfd_reloc_notsupported, /* Unused. */ bfd_reloc_other, /* The symbol to relocate against was undefined. */ bfd_reloc_undefined, /* The relocation was performed, but may not be ok - presently generated only when linking i960 coff files with i960 b.out symbols. If this type is returned, the error_message argument to bfd_perform_relocation will be set. */ bfd_reloc_dangerous } bfd_reloc_status_type; typedef struct reloc_cache_entry { /* A pointer into the canonical table of pointers. */ struct bfd_symbol **sym_ptr_ptr; /* offset in section. */ bfd_size_type address; /* addend for relocation value. */ bfd_vma addend; /* Pointer to how to perform the required relocation. */ reloc_howto_type *howto; } arelent; |
arelent
:
sym_ptr_ptr
canonicalize_symtab
action. See section 2.7 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.
address
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.
addend
addend
is a value provided by the back end to be added (!)
to the relocation offset. Its interpretation is dependent upon
the howto. For example, on the 68k the code:
char foo[]; main() { return foo[0x12345678]; } |
Could be compiled into:
linkw fp,#-4 moveb @#12345678,d0 extbl d0 unlk fp rts |
This could create a reloc pointing to foo
, but leave the
offset in the data, something like:
RELOCATION RECORDS FOR [.text]: offset type value 00000006 32 _foo 00000000 4e56 fffc ; linkw fp,#-4 00000004 1039 1234 5678 ; moveb @#12345678,d0 0000000a 49c0 ; extbl d0 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:
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:
RELOCATION RECORDS FOR [.text]: offset type value 00000002 HVRT16 _foo+0x12340000 00000006 LVRT16 _foo+0x12340000 00000000 5da05678 ; or.u r13,r0,0x5678 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.
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 ldsb [%g2+%lo(_foo+0x12345678)],%i0 ret restore |
Both relocs contain a pointer to foo
, and the offsets
contain junk.
RELOCATION RECORDS FOR [.text]: offset type value 00000004 HI22 _foo+0x12345678 00000008 LO10 _foo+0x12345678 00000000 9de3bf90 ; save %sp,-112,%sp 00000004 05000000 ; sethi %hi(_foo+0),%g2 00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0 0000000c 81c7e008 ; ret 00000010 81e80000 ; restore |
howto
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |