]> Top Information Loss Information can be lost during output. The output formats supported by BFD do not provide identical facilities, and information which can be described in one form has nowhere to go in another format. One example of this is alignment information in b.out. There is nowhere in an a.out format file to store alignment information on the contained data, so when a file is linked from b.out and an a.out image is produced, alignment information will not propagate to the output file. (The linker will still use the alignment information internally, so the link is performed correctly). Another example is COFF section names. COFF files may contain an unlimited number of sections, each one with a textual section name. If the target of the link is a format which does not have many sections (e.g., a.out) or has sections without names (e.g., the Oasys format), the link cannot be done simply. You can circumvent this problem by describing the desired input-to-output section mapping with the linker command language. Information can be lost during canonicalization. The BFD internal canonical form of the external formats is not exhaustive; there are structures in input formats for which there is no direct representation internally. This means that the BFD back ends cannot maintain all possible data richness through the transformation between external to internal and back to external formats. This limitation is only a problem when an application reads one format and writes another. Each BFD back end is responsible for maintaining as much data as possible, and the internal BFD canonical form has structures which are opaque to the BFD core, and exported only to the back ends. When a file is read in one format, the canonical form is generated for BFD and the application. At the same time, the back end saves away any information which may otherwise be lost. If the data is then written back in the same format, the back end routine will be able to use the canonical form provided by the BFD core as well as the information it prepared earlier. Since there is a great deal of commonality between back ends, there is no information lost when linking or copying big endian COFF to little endian COFF, or a.out to b.out. When a mixture of formats is linked, the information is only lost from the files whose format differs from the destination. The BFD canonical object-file format The greatest potential for loss of information occurs when there is the least overlap between the information provided by the source format, that stored by the canonical format, and that needed by the destination format. A brief description of the canonical form may help you understand which kinds of data you can count on preserving across conversions. BFD canonical format internal object-file format files Information stored on a per-file basis includes target machinearchitecture, particular implementation format type, a demand pageablebit, and a write protected bit. Information like Unix magic numbers isnot stored here—only the magic numbers' meaning, so a ZMAGICfile would have both the demand pageable bit and the write protectedtext bit set. The byte order of the target is stored on a per-filebasis, so that big- and little-endian object files may be used with oneanother. sections Each section in the input file contains the name of the section, thesection's original address in the object file, size and alignmentinformation, various flags, and pointers into other BFD datastructures. symbols Each symbol contains a pointer to the information for the object filewhich originally defined it, its name, its value, and various flagbits. When a BFD back end reads in a symbol table, it relocates allsymbols to make them relative to the base of the section where they weredefined. Doing this ensures that each symbol points to its containingsection. Each symbol also has a varying amount of hidden private datafor the BFD back end. Since the symbol points to the original file, theprivate data format for that symbol is accessible. ld canoperate on a collection of symbols of wildly different formats withoutproblems.Normal global and simple local symbols are maintained on output, so anoutput file (no matter its format) will retain symbols pointing tofunctions and to global, static, and common variables. Some symbolinformation is not worth retaining; in a.out, type information isstored in the symbol table as long symbol names. This information wouldbe useless to most COFF debuggers; the linker has command line switchesto allow users to throw it away.There is one word of type information within the symbol, so if theformat supports symbol type information within symbols (for example, COFF,IEEE, Oasys) and the type is simple enough to fit within one word(nearly everything but aggregates), the information will be preserved. relocation level Each canonical BFD relocation record contains a pointer to the symbol torelocate to, the offset of the data to relocate, the section the datais in, and a pointer to a relocation type descriptor. Relocation isperformed by passing messages through the relocation typedescriptor and the symbol pointer. Therefore, relocations can be performedon output data using a relocation method that is only available in one of theinput formats. For instance, Oasys provides a byte relocation format.A relocation record requesting this relocation type would pointindirectly to a routine to perform this, so the relocation may beperformed on a byte being written to a 68k COFF file, even though 68k COFFhas no such relocation type. line numbers Object formats can contain, for debugging purposes, some form of mappingbetween symbols, source line numbers, and addresses in the output file.These addresses have to be relocated along with the symbol information.Each symbol with an associated list of line number records points to thefirst record of the list. The head of a line number list consists of apointer to the symbol, which allows finding out the address of thefunction whose line number is being described. The rest of the list ismade up of pairs: offsets into the section and line numbers. Any formatwhich can simply derive this information can pass it successfullybetween formats (COFF, IEEE and Oasys).