lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory Ref-docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:21:47 -05:00
parent 5a46ddb732
commit ef50495c9d
2492 changed files with 1609142 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

224
Ref-docs/manual ld/ld_5.html Normal file
View File

@@ -0,0 +1,224 @@
<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>