The Bfd Canonical Object-File Format - Red Hat ENTERPRISE LINUX 3 - USING ID Using Instructions

68
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 to . When a mixture of formats is linked, the information is only lost from the files
a.out b.out
whose format differs from the destination.
6.1.2. 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.
files
Information stored on a per-file basis includes target machine architecture, particular implemen-
tation format type, a demand pageable bit, and a write protected bit. Information like Unix magic
numbers is not stored here--only the magic numbers' meaning, so a
the demand pageable bit and the write protected text bit set. The byte order of the target is stored
on a per-file basis, so that big- and little-endian object files may be used with one another.
sections
Each section in the input file contains the name of the section, the section's original address in
the object file, size and alignment information, various flags, and pointers into other BFD data
structures.
symbols
Each symbol contains a pointer to the information for the object file which originally defined
it, its name, its value, and various flag bits. When a BFD back end reads in a symbol table, it
relocates all symbols to make them relative to the base of the section where they were defined.
Doing this ensures that each symbol points to its containing section. Each symbol also has a
varying amount of hidden private data for the BFD back end. Since the symbol points to the
original file, the private data format for that symbol is accessible.
of symbols of wildly different formats without problems.
Normal global and simple local symbols are maintained on output, so an output file (no matter
its format) will retain symbols pointing to functions and to global, static, and common variables.
Some symbol information is not worth retaining; in
symbol table as long symbol names. This information would be useless to most COFF debuggers;
the linker has command line switches to allow users to throw it away.
There is one word of type information within the symbol, so if the format 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 to relocate to, the offset
of the data to relocate, the section the data is in, and a pointer to a relocation type descriptor.
Relocation is performed by passing messages through the relocation type descriptor and the
symbol pointer. Therefore, relocations can be performed on output data using a relocation method
ZMAGIC
can operate on a collection
ld
, type information is stored in the
a.out
Chapter 6. BFD
file would have both