225 lines
9.9 KiB
HTML
225 lines
9.9 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<!-- This HTML file has been created by texi2html 1.52
|
|
from ../texi/ld.texinfo on 7 November 1998 -->
|
|
|
|
<TITLE>Using LD, the GNU linker - BFD</TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
Go to the <A HREF="ld_1.html">first</A>, <A HREF="ld_4.html">previous</A>, <A HREF="ld_6.html">next</A>, <A HREF="ld_8.html">last</A> section, <A HREF="ld_toc.html">table of contents</A>.
|
|
<P><HR><P>
|
|
|
|
|
|
<H1><A NAME="SEC30" HREF="ld_toc.html#TOC30">BFD</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX366"></A>
|
|
<A NAME="IDX367"></A>
|
|
<A NAME="IDX368"></A>
|
|
<A NAME="IDX369"></A>
|
|
The linker accesses object and archive files using the BFD libraries.
|
|
These libraries allow the linker to use the same routines to operate on
|
|
object files whatever the object file format. A different object file
|
|
format can be supported simply by creating a new BFD back end and adding
|
|
it to the library. To conserve runtime memory, however, the linker and
|
|
associated tools are usually configured to support only a subset of the
|
|
object file formats available. You can use <CODE>objdump -i</CODE>
|
|
(see section `objdump' in <CITE>The GNU Binary Utilities</CITE>) to
|
|
list all the formats available for your configuration.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX370"></A>
|
|
<A NAME="IDX371"></A>
|
|
As with most implementations, BFD is a compromise between
|
|
several conflicting requirements. The major factor influencing
|
|
BFD design was efficiency: any time used converting between
|
|
formats is time which would not have been spent had BFD not
|
|
been involved. This is partly offset by abstraction payback; since
|
|
BFD simplifies applications and back ends, more time and care
|
|
may be spent optimizing algorithms for a greater speed.
|
|
|
|
</P>
|
|
<P>
|
|
One minor artifact of the BFD solution which you should bear in
|
|
mind is the potential for information loss. There are two places where
|
|
useful information can be lost using the BFD mechanism: during
|
|
conversion and during output. See section <A HREF="ld_5.html#SEC32">Information Loss</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC31" HREF="ld_toc.html#TOC31">How it works: an outline of BFD</A></H2>
|
|
<P>
|
|
<A NAME="IDX372"></A>
|
|
When an object file is opened, BFD subroutines automatically determine
|
|
the format of the input object file. They then build a descriptor in
|
|
memory with pointers to routines that will be used to access elements of
|
|
the object file's data structures.
|
|
|
|
</P>
|
|
<P>
|
|
As different information from the the object files is required,
|
|
BFD reads from different sections of the file and processes them.
|
|
For example, a very common operation for the linker is processing symbol
|
|
tables. Each BFD back end provides a routine for converting
|
|
between the object file's representation of symbols and an internal
|
|
canonical format. When the linker asks for the symbol table of an object
|
|
file, it calls through a memory pointer to the routine from the
|
|
relevant BFD back end which reads and converts the table into a canonical
|
|
form. The linker then operates upon the canonical form. When the link is
|
|
finished and the linker writes the output file's symbol table,
|
|
another BFD back end routine is called to take the newly
|
|
created symbol table and convert it into the chosen output format.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC32" HREF="ld_toc.html#TOC32">Information Loss</A></H3>
|
|
|
|
<P>
|
|
<EM>Information can be lost during output.</EM> 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
|
|
<CODE>b.out</CODE>. There is nowhere in an <CODE>a.out</CODE> format file to store
|
|
alignment information on the contained data, so when a file is linked
|
|
from <CODE>b.out</CODE> and an <CODE>a.out</CODE> 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).
|
|
|
|
</P>
|
|
<P>
|
|
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.,
|
|
<CODE>a.out</CODE>) 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.
|
|
|
|
</P>
|
|
<P>
|
|
<EM>Information can be lost during canonicalization.</EM> 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.
|
|
|
|
</P>
|
|
<P>
|
|
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 <CODE>a.out</CODE> to
|
|
<CODE>b.out</CODE>. When a mixture of formats is linked, the information is
|
|
only lost from the files whose format differs from the destination.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC33" HREF="ld_toc.html#TOC33">The BFD canonical object-file format</A></H3>
|
|
|
|
<P>
|
|
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.
|
|
<A NAME="IDX373"></A>
|
|
<A NAME="IDX374"></A>
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>files</EM>
|
|
<DD>
|
|
Information stored on a per-file basis includes target machine
|
|
architecture, particular implementation 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 <CODE>ZMAGIC</CODE>
|
|
file would have both 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.
|
|
|
|
<DT><EM>sections</EM>
|
|
<DD>
|
|
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.
|
|
|
|
<DT><EM>symbols</EM>
|
|
<DD>
|
|
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. <CODE>ld</CODE> can
|
|
operate on a collection 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 <CODE>a.out</CODE>, type information is
|
|
stored in the 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.
|
|
|
|
<DT><EM>relocation level</EM>
|
|
<DD>
|
|
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 that is only available in one of the
|
|
input formats. For instance, Oasys provides a byte relocation format.
|
|
A relocation record requesting this relocation type would point
|
|
indirectly to a routine to perform this, so the relocation may be
|
|
performed on a byte being written to a 68k COFF file, even though 68k COFF
|
|
has no such relocation type.
|
|
|
|
<DT><EM>line numbers</EM>
|
|
<DD>
|
|
Object formats can contain, for debugging purposes, some form of mapping
|
|
between 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 the
|
|
first record of the list. The head of a line number list consists of a
|
|
pointer to the symbol, which allows finding out the address of the
|
|
function whose line number is being described. The rest of the list is
|
|
made up of pairs: offsets into the section and line numbers. Any format
|
|
which can simply derive this information can pass it successfully
|
|
between formats (COFF, IEEE and Oasys).
|
|
</DL>
|
|
|
|
<P><HR><P>
|
|
Go to the <A HREF="ld_1.html">first</A>, <A HREF="ld_4.html">previous</A>, <A HREF="ld_6.html">next</A>, <A HREF="ld_8.html">last</A> section, <A HREF="ld_toc.html">table of contents</A>.
|
|
</BODY>
|
|
</HTML>
|