[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Most object file formats have information which BFD can not represent in its generic form, at least as currently defined.
There is often explicit information which BFD can not represent. For example, the COFF version stamp, or the ELF program segments. BFD provides special hooks to handle this information when copying, printing, or linking an object file. The BFD support for a particular object file format will normally store this information in private data and handle it using the special hooks.
In some cases there is also implicit information which BFD can not represent. For example, the MIPS processor distinguishes small and large symbols, and requires that all small symbls be within 32K of the GP register. This means that the MIPS assembler must be able to mark variables as either small or large, and the MIPS linker must know to put small symbols within range of the GP register. Since BFD can not represent this information, this means that the assembler and linker must have information that is specific to a particular object file format which is outside of the BFD library.
This loss of information indicates areas where the BFD paradigm breaks down. It is not actually possible to represent the myriad differences among object file formats using a single generic interface, at least not in the manner which BFD does it today.
Nevertheless, the BFD library does greatly simplify the task of dealing with object files, and particular problems caused by information loss can normally be solved using some sort of relatively constrained hook into the library.