[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.2 BFD relocation functions

In BFD, each section has an array of `arelent' structures. Each structure has a pointer to a symbol, an address within the section, an addend, and a pointer to a `reloc_howto_struct' structure. The howto structure has a bunch of fields describing the reloc, including a type field. The type field is specific to the object file format backend; none of the generic code in BFD examines it.

Originally, the function `bfd_perform_relocation' was supposed to handle all relocations. In theory, many relocations would be simple enough to be described by the fields in the howto structure. For those that weren't, the howto structure included a `special_function' field to use as an escape.

While this seems plausible, a look at `bfd_perform_relocation' shows that it failed. The function has odd special cases. Some of the fields in the howto structure, such as `pcrel_offset', were not adequately documented.

The linker uses `bfd_perform_relocation' to do all relocations when the input and output file have different formats (e.g., when generating S-records). The generic linker code, which is used by all targets which do not define their own special purpose linker, uses `bfd_get_relocated_section_contents', which for most targets turns into a call to `bfd_generic_get_relocated_section_contents', which calls `bfd_perform_relocation'. So `bfd_perform_relocation' is still widely used, which makes it difficult to change, since it is difficult to test all possible cases.

The assembler used `bfd_perform_relocation' for a while. This turned out to be the wrong thing to do, since `bfd_perform_relocation' was written to handle relocations on an existing object file, while the assembler needed to create relocations in a new object file. The assembler was changed to use the new function `bfd_install_relocation' instead, and `bfd_install_relocation' was created as a copy of `bfd_perform_relocation'.

Unfortunately, the work did not progress any farther, so `bfd_install_relocation' remains a simple copy of `bfd_perform_relocation', with all the odd special cases and confusing code. This again is difficult to change, because again any change can affect any assembler target, and so is difficult to test.

The new linker, when using the same object file format for all input files and the output file, does not convert relocations into `arelent' structures, so it can not use `bfd_perform_relocation' at all. Instead, users of the new linker are expected to write a `relocate_section' function which will handle relocations in a target specific fashion.

There are two helper functions for target specific relocation: `_bfd_final_link_relocate' and `_bfd_relocate_contents'. These functions use a howto structure, but they do not use the `special_function' field. Since the functions are normally called from target specific code, the `special_function' field adds little; any relocations which require special handling can be handled without calling those functions.

So, if you want to add a new target, or add a new relocation to an existing target, you need to do the following:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by system on December, 2 2004 using texi2html