[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The linker will be much more efficient if you define a relocate section function. This will permit BFD to use the ELF specific linker support.
If you do not define a relocate section function, BFD must use the generic linker support, which requires converting all symbols and relocations into BFD `asymbol' and `arelent' structures. In this case, relocations will be handled by calling `bfd_perform_relocation', which will use the howto structures you have defined. See section 6. BFD relocation handling.
In order to support linking into a different object file format, such as S-records, `bfd_perform_relocation' must work correctly with your howto structures, so you can't skip that step. However, if you define the relocate section function, then in the normal case of linking into an ELF file the linker will not need to convert symbols and relocations, and will be much more efficient.
To use a relocation section function, define the macro `elf_backend_relocate_section' as the name of a function which will take the contents of a section, as well as relocation, symbol, and other information, and modify the section contents according to the relocation information. In simple cases, this is little more than a loop over the relocations which computes the value of each relocation and calls `_bfd_final_link_relocate'. The function must check for a relocatable link, and in that case normally needs to do nothing other than adjust the addend for relocations against a section symbol.
The complex cases generally have to do with dynamic linker support. GOT and PLT relocations must be handled specially, and the linker normally arranges to set up the GOT and PLT sections while handling relocations. When generating a shared library, random relocations must normally be copied into the shared library, or converted to RELATIVE relocations when possible.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |