bfdint.texi

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

The new linker, when using the same object file format for all input
files and the output file, does not convert relocations into
@samp{arelent} structures, so it can not use
@samp{bfd_perform_relocation} at all.  Instead, users of the new linker
are expected to write a @samp{relocate_section} function which will
handle relocations in a target specific fashion.

There are two helper functions for target specific relocation:
@samp{_bfd_final_link_relocate} and @samp{_bfd_relocate_contents}.
These functions use a howto structure, but they @emph{do not} use the
@samp{special_function} field.  Since the functions are normally called
from target specific code, the @samp{special_function} field adds
little; any relocations which require special handling can be handled
without calling those functions.

So, if you want to add a new target, or add a new relocation to an
existing target, you need to do the following:

@itemize @bullet
@item
Make sure you clearly understand what the contents of the section should
look like after assembly, after a relocatable link, and after a final
link.  Make sure you clearly understand the operations the linker must
perform during a relocatable link and during a final link.

@item
Write a howto structure for the relocation.  The howto structure is
flexible enough to represent any relocation which should be handled by
setting a contiguous bitfield in the destination to the value of a
symbol, possibly with an addend, possibly adding the symbol value to the
value already present in the destination.

@item
Change the assembler to generate your relocation.  The assembler will
call @samp{bfd_install_relocation}, so your howto structure has to be
able to handle that.  You may need to set the @samp{special_function}
field to handle assembly correctly.  Be careful to ensure that any code
you write to handle the assembler will also work correctly when doing a
relocatable link.  For example, see @samp{bfd_elf_generic_reloc}.

@item
Test the assembler.  Consider the cases of relocation against an
undefined symbol, a common symbol, a symbol defined in the object file
in the same section, and a symbol defined in the object file in a
different section.  These cases may not all be applicable for your
reloc.

@item
If your target uses the new linker, which is recommended, add any
required handling to the target specific relocation function.  In simple
cases this will just involve a call to @samp{_bfd_final_link_relocate}
or @samp{_bfd_relocate_contents}, depending upon the definition of the
relocation and whether the link is relocatable or not.

@item
Test the linker.  Test the case of a final link.  If the relocation can
overflow, use a linker script to force an overflow and make sure the
error is reported correctly.  Test a relocatable link, whether the
symbol is defined or undefined in the relocatable output.  For both the
final and relocatable link, test the case when the symbol is a common
symbol, when the symbol looked like a common symbol but became a defined
symbol, when the symbol is defined in a different object file, and when
the symbol is defined in the same object file.

@item
In order for linking to another object file format, such as S-records,
to work correctly, @samp{bfd_perform_relocation} has to do the right
thing for the relocation.  You may need to set the
@samp{special_function} field to handle this correctly.  Test this by
doing a link in which the output object file format is S-records.

@item
Using the linker to generate relocatable output in a different object
file format is impossible in the general case, so you generally don't
have to worry about that.  The GNU linker makes sure to stop that from
happening when an input file in a different format has relocations.

Linking input files of different object file formats together is quite
unusual, but if you're really dedicated you may want to consider testing
this case, both when the output object file format is the same as your
format, and when it is different.
@end itemize

@node BFD relocation codes
@subsection BFD relocation codes

BFD has another way of describing relocations besides the howto
structures described above: the enum @samp{bfd_reloc_code_real_type}.

Every known relocation type can be described as a value in this
enumeration.  The enumeration contains many target specific relocations,
but where two or more targets have the same relocation, a single code is
used.  For example, the single value @samp{BFD_RELOC_32} is used for all
simple 32 bit relocation types.

The main purpose of this relocation code is to give the assembler some
mechanism to create @samp{arelent} structures.  In order for the
assembler to create an @samp{arelent} structure, it has to be able to
obtain a howto structure.  The function @samp{bfd_reloc_type_lookup},
which simply calls the target vector entry point
@samp{reloc_type_lookup}, takes a relocation code and returns a howto
structure.

The function @samp{bfd_get_reloc_code_name} returns the name of a
relocation code.  This is mainly used in error messages.

Using both howto structures and relocation codes can be somewhat
confusing.  There are many processor specific relocation codes.
However, the relocation is only fully defined by the howto structure.
The same relocation code will map to different howto structures in
different object file formats.  For example, the addend handling may be
different.

Most of the relocation codes are not really general.  The assembler can
not use them without already understanding what sorts of relocations can
be used for a particular target.  It might be possible to replace the
relocation codes with something simpler.

@node BFD relocation future
@subsection BFD relocation future

Clearly the current BFD relocation support is in bad shape.  A
wholescale rewrite would be very difficult, because it would require
thorough testing of every BFD target.  So some sort of incremental
change is required.

My vague thoughts on this would involve defining a new, clearly defined,
howto structure.  Some mechanism would be used to determine which type
of howto structure was being used by a particular format.

The new howto structure would clearly define the relocation behaviour in
the case of an assembly, a relocatable link, and a final link.  At
least one special function would be defined as an escape, and it might
make sense to define more.

One or more generic functions similar to @samp{bfd_perform_relocation}
would be written to handle the new howto structure.

This should make it possible to write a generic version of the relocate
section functions used by the new linker.  The target specific code
would provide some mechanism (a function pointer or an initial
conversion) to convert target specific relocations into howto
structures.

Ideally it would be possible to use this generic relocate section
function for the generic linker as well.  That is, it would replace the
@samp{bfd_generic_get_relocated_section_contents} function which is
currently normally used.

For the special case of ELF dynamic linking, more consideration needs to
be given to writing ELF specific but ELF target generic code to handle
special relocation types such as GOT and PLT.

@node BFD ELF support
@section BFD ELF support
@cindex elf support in bfd
@cindex bfd elf support

The ELF object file format is defined in two parts: a generic ABI and a
processor specific supplement.  The ELF support in BFD is split in a
similar fashion.  The processor specific support is largely kept within
a single file.  The generic support is provided by several other files.
The processor specific support provides a set of function pointers and
constants used by the generic support.

@menu
* BFD ELF sections and segments::	ELF sections and segments
* BFD ELF generic support::		BFD ELF generic support
* BFD ELF processor specific support::	BFD ELF processor specific support
* BFD ELF core files::			BFD ELF core files
* BFD ELF future::			BFD ELF future
@end menu

@node BFD ELF sections and segments
@subsection ELF sections and segments

The ELF ABI permits a file to have either sections or segments or both.
Relocateable object files conventionally have only sections.
Executables conventionally have both.  Core files conventionally have
only program segments.

ELF sections are similar to sections in other object file formats: they
have a name, a VMA, file contents, flags, and other miscellaneous
information.  ELF relocations are stored in sections of a particular
type; BFD automatically converts these sections into internal relocation
information.

ELF program segments are intended for fast interpretation by a system
loader.  They have a type, a VMA, an LMA, file contents, and a couple of
other fields.  When an ELF executable is run on a Unix system, the
system loader will examine the program segments to decide how to load
it.  The loader will ignore the section information.  Loadable program
segments (type @samp{PT_LOAD}) are directly loaded into memory.  Other
program segments are interpreted by the loader, and generally provide
dynamic linking information.

When an ELF file has both program segments and sections, an ELF program
segment may encompass one or more ELF sections, in the sense that the
portion of the file which corresponds to the program segment may include
the portions of the file corresponding to one or more sections.  When
there is more than one section in a loadable program segment, the
relative positions of the section contents in the file must correspond
to the relative positions they should hold when the program segment is
loaded.  This requirement should be obvious if you consider that the
system loader will load an entire program segment at a time.

On a system which supports dynamic paging, such as any native Unix
system, the contents of a loadable program segment must be at the same
offset in the file as in memory, modulo the memory page size used on the
system.  This is because the system loader will map the file into memory
starting at the start of a page.  The system loader can easily remap
entire pages to the correct load address.  However, if the contents of
the file were not correctly aligned within the page, the system loader
would have to shift the contents around within the page, which is too
expensive.  For example, if the LMA of a loadable program segment is
@samp{0x40080} and the page size is @samp{0x1000}, then the position of
the segment contents within the file must equal @samp{0x80} modulo
@samp{0x1000}.

BFD has only a single set of sections.  It does not provide any generic
way to examine both sections and segments.  When BFD is used to open an
object file or executable, the BFD sections will represent ELF sections.
When BFD is used to open a core file, the BFD sections will represent
ELF program segments.

When BFD is used to examine an object file or executable, any program
segments will be read to set the LMA of the sections.  This is because
ELF sections only have a VMA, while ELF program segments have both a VMA
and an LMA.  Any program segments will be copied by the
@samp{copy_private} entry points.  They will be printed by the
@samp{print_private} entry point.  Otherwise, the program segments are
ignored.  In particular, programs which use BFD currently have no direct
access to the program segments.

When BFD is used to create an executable, the program segments will be
created automatically based on the section information.  This is done in
the function @samp{assign_file_positions_for_segments} in @file{elf.c}.
This function has been tweaked many times, and probably still has
problems that arise in particular cases.

There is a hook which may be used to explicitly define the program
segments when creating an executable: the @samp{bfd_record_phdr}
function in @file{bfd.c}.  If this function is called, BFD will not
create program segments itself, but will only create the program
segments specified by the caller.  The linker uses this function to
implement the @samp{PHDRS} linker script command.

@node BFD ELF generic support
@subsection BFD ELF generic support

In general, functions which do not read external data from the ELF file
are found in @file{elf.c}.  They operate on the internal forms of the
ELF structures, which are defined in @file{include/elf/internal.h}.  The
internal structures are defined in terms of @samp{bfd_vma}, and so may
be used for both 32 bit and 64 bit ELF targets.

The file @file{elfcode.h} contains functions which operate on the
external data.  @file{elfcode.h} is compiled twice, once via
@file{elf32.c} with @samp{ARCH_SIZE} defined as @samp{32}, and once via
@file{elf64.c} with @samp{ARCH_SIZE} defined as @samp{64}.
@file{elfcode.h} includes functions to swap the ELF structures in and
out of external form, as well as a few more complex functions.

Linker support is found in @file{elflink.c}.  The
linker support is only used if the processor specific file defines
@samp{elf_backend_relocate_section}, which is required to relocate the
section contents.  If that macro is not defined, the generic linker code
is used, and relocations are handled via @samp{bfd_perform_relocation}.

The core file support is in @file{elfcore.h}, which is compiled twice,
for both 32 and 64 bit support.  The more interesting cases of core file
support only work on a native system which has the @file{sys/procfs.h}
header file.  Without that file, the core file support does little more
than read the ELF program segments as BFD sections.

The BFD internal header file @file{elf-bfd.h} is used for communication
among these files and the processor specific files.

The default entries for the BFD ELF target vector are found mainly in
@file{elf.c}.  Some functions are found in @file{elfcode.h}.

The processor specific files may override particular entries in the
target vector, but most do not, with one exception: the
@samp{bfd_reloc_type_lookup} entry point is always processor specific.

@node BFD ELF processor specific support
@subsection BFD ELF processor specific support

By convention, the processor specific support for a particular processor
will be found in @file{elf@var{nn}-@var{cpu}.c}, where @var{nn} is
either 32 or 64, and @var{cpu} is the name of the processor.

@menu
* BFD ELF processor required::	Required processor specific support
* BFD ELF processor linker::	Processor specific linker support
* BFD ELF processor other::	Other processor specific support options
@end menu

@node BFD ELF processor required
@subsubsection Required processor specific support

When writing a @fil