bfdint.texi

这个是LINUX下的GDB调度工具的源码

\input texinfo
@c Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998,
@c 2000, 2001, 2002, 2003
@c Free Software Foundation, Inc.
@setfilename bfdint.info

@settitle BFD Internals
@iftex
@titlepage
@title{BFD Internals}
@author{Ian Lance Taylor}
@author{Cygnus Solutions}
@page
@end iftex

@node Top
@top BFD Internals
@raisesections
@cindex bfd internals

This document describes some BFD internal information which may be
helpful when working on BFD.  It is very incomplete.

This document is not updated regularly, and may be out of date.

The initial version of this document was written by Ian Lance Taylor
@email{ian@@cygnus.com}.

@menu
* BFD overview::		BFD overview
* BFD guidelines::		BFD programming guidelines
* BFD target vector::		BFD target vector
* BFD generated files::		BFD generated files
* BFD multiple compilations::	Files compiled multiple times in BFD
* BFD relocation handling::	BFD relocation handling
* BFD ELF support::		BFD ELF support
* BFD glossary::		Glossary
* Index::			Index
@end menu

@node BFD overview
@section BFD overview

BFD is a library which provides a single interface to read and write
object files, executables, archive files, and core files in any format.

@menu
* BFD library interfaces::	BFD library interfaces
* BFD library users::		BFD library users
* BFD view::			The BFD view of a file
* BFD blindness::		BFD loses information
@end menu

@node BFD library interfaces
@subsection BFD library interfaces

One way to look at the BFD library is to divide it into four parts by
type of interface.

The first interface is the set of generic functions which programs using
the BFD library will call.  These generic function normally translate
directly or indirectly into calls to routines which are specific to a
particular object file format.  Many of these generic functions are
actually defined as macros in @file{bfd.h}.  These functions comprise
the official BFD interface.

The second interface is the set of functions which appear in the target
vectors.  This is the bulk of the code in BFD.  A target vector is a set
of function pointers specific to a particular object file format.  The
target vector is used to implement the generic BFD functions.  These
functions are always called through the target vector, and are never
called directly.  The target vector is described in detail in @ref{BFD
target vector}.  The set of functions which appear in a particular
target vector is often referred to as a BFD backend.

The third interface is a set of oddball functions which are typically
specific to a particular object file format, are not generic functions,
and are called from outside of the BFD library.  These are used as hooks
by the linker and the assembler when a particular object file format
requires some action which the BFD generic interface does not provide.
These functions are typically declared in @file{bfd.h}, but in many
cases they are only provided when BFD is configured with support for a
particular object file format.  These functions live in a grey area, and
are not really part of the official BFD interface.

The fourth interface is the set of BFD support functions which are
called by the other BFD functions.  These manage issues like memory
allocation, error handling, file access, hash tables, swapping, and the
like.  These functions are never called from outside of the BFD library.

@node BFD library users
@subsection BFD library users

Another way to look at the BFD library is to divide it into three parts
by the manner in which it is used.

The first use is to read an object file.  The object file readers are
programs like @samp{gdb}, @samp{nm}, @samp{objdump}, and @samp{objcopy}.
These programs use BFD to view an object file in a generic form.  The
official BFD interface is normally fully adequate for these programs.

The second use is to write an object file.  The object file writers are
programs like @samp{gas} and @samp{objcopy}.  These programs use BFD to
create an object file.  The official BFD interface is normally adequate
for these programs, but for some object file formats the assembler needs
some additional hooks in order to set particular flags or other
information.  The official BFD interface includes functions to copy
private information from one object file to another, and these functions
are used by @samp{objcopy} to avoid information loss.

The third use is to link object files.  There is only one object file
linker, @samp{ld}.  Originally, @samp{ld} was an object file reader and
an object file writer, and it did the link operation using the generic
BFD structures.  However, this turned out to be too slow and too memory
intensive.

The official BFD linker functions were written to permit specific BFD
backends to perform the link without translating through the generic
structures, in the normal case where all the input files and output file
have the same object file format.  Not all of the backends currently
implement the new interface, and there are default linking functions
within BFD which use the generic structures and which work with all
backends.

For several object file formats the linker needs additional hooks which
are not provided by the official BFD interface, particularly for dynamic
linking support.  These functions are typically called from the linker
emulation template.

@node BFD view
@subsection The BFD view of a file

BFD uses generic structures to manage information.  It translates data
into the generic form when reading files, and out of the generic form
when writing files.

BFD describes a file as a pointer to the @samp{bfd} type.  A @samp{bfd}
is composed of the following elements.  The BFD information can be
displayed using the @samp{objdump} program with various options.

@table @asis
@item general information
The object file format, a few general flags, the start address.
@item architecture
The architecture, including both a general processor type (m68k, MIPS
etc.) and a specific machine number (m68000, R4000, etc.).
@item sections
A list of sections.
@item symbols
A symbol table.
@end table

BFD represents a section as a pointer to the @samp{asection} type.  Each
section has a name and a size.  Most sections also have an associated
block of data, known as the section contents.  Sections also have
associated flags, a virtual memory address, a load memory address, a
required alignment, a list of relocations, and other miscellaneous
information.

BFD represents a relocation as a pointer to the @samp{arelent} type.  A
relocation describes an action which the linker must take to modify the
section contents.  Relocations have a symbol, an address, an addend, and
a pointer to a howto structure which describes how to perform the
relocation.  For more information, see @ref{BFD relocation handling}.

BFD represents a symbol as a pointer to the @samp{asymbol} type.  A
symbol has a name, a pointer to a section, an offset within that
section, and some flags.

Archive files do not have any sections or symbols.  Instead, BFD
represents an archive file as a file which contains a list of
@samp{bfd}s.  BFD also provides access to the archive symbol map, as a
list of symbol names.  BFD provides a function to return the @samp{bfd}
within the archive which corresponds to a particular entry in the
archive symbol map.

@node BFD blindness
@subsection BFD loses information

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.



@node BFD guidelines
@section BFD programming guidelines
@cindex bfd programming guidelines
@cindex programming guidelines for bfd
@cindex guidelines, bfd programming

There is a lot of poorly written and confusing code in BFD.  New BFD
code should be written to a higher standard.  Merely because some BFD
code is written in a particular manner does not mean that you should
emulate it.

Here are some general BFD programming guidelines:

@itemize @bullet
@item
Follow the GNU coding standards.

@item
Avoid global variables.  We ideally want BFD to be fully reentrant, so
that it can be used in multiple threads.  All uses of global or static
variables interfere with that.  Initialized constant variables are OK,
and they should be explicitly marked with const.  Instead of global
variables, use data attached to a BFD or to a linker hash table.

@item
All externally visible functions should have names which start with
@samp{bfd_}.  All such functions should be declared in some header file,
typically @file{bfd.h}.  See, for example, the various declarations near
the end of @file{bfd-in.h}, which mostly declare functions required by
specific linker emulations.

@item
All functions which need to be visible from one file to another within
BFD, but should not be visible outside of BFD, should start with
@samp{_bfd_}.  Although external names beginning with @samp{_} are
prohibited by the ANSI standard, in practice this usage will always
work, and it is required by the GNU coding standards.

@item
Always remember that people can compile using @samp{--enable-targets} to
build several, or all, targets at once.  It must be possible to link
together the files for all targets.

@item
BFD code should compile with few or no warnings using @samp{gcc -Wall}.
Some warnings are OK, like the absence of certain function declarations
which may or may not be declared in system header files.  Warnings about
ambiguous expressions and the like should always be fixed.
@end itemize

@node BFD target vector
@section BFD target vector
@cindex bfd target vector
@cindex target vector in bfd

BFD supports multiple object file formats by using the @dfn{target
vector}.  This is simply a set of function pointers which implement
behaviour that is specific to a particular object file format.

In this section I list all of the entries in the target vector and
describe what they do.

@menu
* BFD target vector miscellaneous::	Miscellaneous constants
* BFD target vector swap::		Swapping functions
* BFD target vector format::		Format type dependent functions
* BFD_JUMP_TABLE macros::		BFD_JUMP_TABLE macros
* BFD target vector generic::		Generic functions
* BFD target vector copy::		Copy functions
* BFD target vector core::		Core file support functions
* BFD target vector archive::		Archive functions
* BFD target vector symbols::		Symbol table functions
* BFD target vector relocs::		Relocation support
* BFD target vector write::		Output functions
* BFD target vector link::		Linker functions
* BFD target vector dynamic::		Dynamic linking information functions
@end menu

@node BFD target vector miscellaneous
@subsection Miscellaneous constants

The target vector starts with a set of constants.

@table @samp
@item name
The name of the target vector.  This is an arbitrary string.  This is
how the target vector is named in command line options for tools which
use BFD, such as the @samp{--oformat} linker option.

@item flavour
A general description of the type of target.  The following flavours are
currently defined: