This is bfdint.info, produced by makeinfo version 4.0 from bfdint.texi.


File: bfdint.info,  Node: BFD relocation functions,  Next: BFD relocation codes,  Prev: BFD relocation concepts,  Up: BFD relocation handling

BFD relocation functions
========================

   In BFD, each section has an array of `arelent' structures.  Each
structure has a pointer to a symbol, an address within the section, an
addend, and a pointer to a `reloc_howto_struct' structure.  The howto
structure has a bunch of fields describing the reloc, including a type
field.  The type field is specific to the object file format backend;
none of the generic code in BFD examines it.

   Originally, the function `bfd_perform_relocation' was supposed to
handle all relocations.  In theory, many relocations would be simple
enough to be described by the fields in the howto structure.  For those
that weren't, the howto structure included a `special_function' field
to use as an escape.

   While this seems plausible, a look at `bfd_perform_relocation' shows
that it failed.  The function has odd special cases.  Some of the
fields in the howto structure, such as `pcrel_offset', were not
adequately documented.

   The linker uses `bfd_perform_relocation' to do all relocations when
the input and output file have different formats (e.g., when generating
S-records).  The generic linker code, which is used by all targets which
do not define their own special purpose linker, uses
`bfd_get_relocated_section_contents', which for most targets turns into
a call to `bfd_generic_get_relocated_section_contents', which calls
`bfd_perform_relocation'.  So `bfd_perform_relocation' is still widely
used, which makes it difficult to change, since it is difficult to test
all possible cases.

   The assembler used `bfd_perform_relocation' for a while.  This
turned out to be the wrong thing to do, since `bfd_perform_relocation'
was written to handle relocations on an existing object file, while the
assembler needed to create relocations in a new object file.  The
assembler was changed to use the new function `bfd_install_relocation'
instead, and `bfd_install_relocation' was created as a copy of
`bfd_perform_relocation'.

   Unfortunately, the work did not progress any farther, so
`bfd_install_relocation' remains a simple copy of
`bfd_perform_relocation', with all the odd special cases and confusing
code.  This again is difficult to change, because again any change can
affect any assembler target, and so is difficult to test.

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

   There are two helper functions for target specific relocation:
`_bfd_final_link_relocate' and `_bfd_relocate_contents'.  These
functions use a howto structure, but they _do not_ use the
`special_function' field.  Since the functions are normally called from
target specific code, the `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:

   * Make sure you clearly understand what the contents of the section
     should look like after assembly, after a relocateable link, and
     after a final link.  Make sure you clearly understand the
     operations the linker must perform during a relocateable link and
     during a final link.

   * 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.

   * Change the assembler to generate your relocation.  The assembler
     will call `bfd_install_relocation', so your howto structure has to
     be able to handle that.  You may need to set the `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 relocateable link.  For example, see
     `bfd_elf_generic_reloc'.

   * 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.

   * 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
     `_bfd_final_link_relocate' or `_bfd_relocate_contents', depending
     upon the definition of the relocation and whether the link is
     relocateable or not.

   * 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
     relocateable link, whether the symbol is defined or undefined in
     the relocateable output.  For both the final and relocateable
     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.

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

   * Using the linker to generate relocateable 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.


File: bfdint.info,  Node: BFD relocation codes,  Next: BFD relocation future,  Prev: BFD relocation functions,  Up: BFD relocation handling

BFD relocation codes
====================

   BFD has another way of describing relocations besides the howto
structures described above: the enum `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 `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 `arelent' structures.  In order for the
assembler to create an `arelent' structure, it has to be able to obtain
a howto structure.  The function `bfd_reloc_type_lookup', which simply
calls the target vector entry point `reloc_type_lookup', takes a
relocation code and returns a howto structure.

   The function `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.


File: bfdint.info,  Node: BFD relocation future,  Prev: BFD relocation codes,  Up: BFD relocation handling

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 relocateable 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 `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
`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.


File: bfdint.info,  Node: BFD ELF support,  Next: BFD glossary,  Prev: BFD relocation handling,  Up: Top

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


File: bfdint.info,  Node: BFD ELF sections and segments,  Next: BFD ELF generic support,  Up: BFD ELF support

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 `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
`0x40080' and the page size is `0x1000', then the position of the
segment contents within the file must equal `0x80' modulo `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 `copy_private'
entry points.  They will be printed by the `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 `assign_file_positions_for_segments' in `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 `bfd_record_phdr' function in
`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 `PHDRS'
linker script command.


File: bfdint.info,  Node: BFD ELF generic support,  Next: BFD ELF processor specific support,  Prev: BFD ELF sections and segments,  Up: BFD ELF support

BFD ELF generic support
=======================

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

   The file `elfcode.h' contains functions which operate on the
external data.  `elfcode.h' is compiled twice, once via `elf32.c' with
`ARCH_SIZE' defined as `32', and once via `elf64.c' with `ARCH_SIZE'
defined as `64'.  `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 `elflink.c' and `elflink.h'.  The latter
file is compiled twice, for both 32 and 64 bit support.  The linker
support is only used if the processor specific file defines
`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 `bfd_perform_relocation'.

   The core file support is in `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 `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 `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
`elf.c'.  Some functions are found in `elfcode.h'.

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


File: bfdint.info,  Node: BFD ELF processor specific support,  Next: BFD ELF core files,  Prev: BFD ELF generic support,  Up: BFD ELF support

BFD ELF processor specific support
==================================

   By convention, the processor specific support for a particular
processor will be found in `elfNN-CPU.c', where NN is either 32 or 64,
and 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


File: bfdint.info,  Node: BFD ELF processor required,  Next: BFD ELF processor linker,  Up: BFD ELF processor specific support

Required processor specific support
-----------------------------------

   When writing a `elfNN-CPU.c' file, you must do the following:

   * Define either `TARGET_BIG_SYM' or `TARGET_LITTLE_SYM', or both, to
     a unique C name to use for the target vector.  This name should
     appear in the list of target vectors in `targets.c', and will also
     have to appear in `config.bfd' and `configure.in'.  Define
     `TARGET_BIG_SYM' for a big-endian processor, `TARGET_LITTLE_SYM'
     for a little-endian processor, and define both for a bi-endian
     processor.

   * Define either `TARGET_BIG_NAME' or `TARGET_LITTLE_NAME', or both,
     to a string used as the name of the target vector.  This is the
     name which a user of the BFD tool would use to specify the object
     file format.  It would normally appear in a linker emulation
     parameters file.

   * Define `ELF_ARCH' to the BFD architecture (an element of the
     `bfd_architecture' enum, typically `bfd_arch_CPU').

   * Define `ELF_MACHINE_CODE' to the magic number which should appear
     in the `e_machine' field of the ELF header.  As of this writing,
     these magic numbers are assigned by SCO; if you want to get a magic
     number for a particular processor, try sending a note to
     <registry@sco.com>.  In the BFD sources, the magic numbers are
     found in `include/elf/common.h'; they have names beginning with
     `EM_'.

   * Define `ELF_MAXPAGESIZE' to the maximum size of a virtual page in
     memory.  This can normally be found at the start of chapter 5 in
     the processor specific supplement.  For a processor which will
     only be used in an embedded system, or which has no memory
     management hardware, this can simply be `1'.

   * If the format should use `Rel' rather than `Rela' relocations,
     define `USE_REL'.  This is normally defined in chapter 4 of the
     processor specific supplement.

     In the absence of a supplement, it's easier to work with `Rela'
     relocations.  `Rela' relocations will require more space in object
     files (but not in executables, except when using dynamic linking).
     However, this is outweighed by the simplicity of addend handling
     when using `Rela' relocations.  With `Rel' relocations, the addend
     must be stored in the section contents, which makes relocateable
     links more complex.

     For example, consider C code like `i = a[1000];' where `a' is a
     global array.  The instructions which load the value of `a[1000]'
     will most likely use a relocation which refers to the symbol
     representing `a', with an addend that gives the offset from the
     start of `a' to element `1000'.  When using `Rel' relocations,
     that addend must be stored in the instructions themselves.  If you
     are adding support for a RISC chip which uses two or more
     instructions to load an address, then the addend may not fit in a
     single instruction, and will have to be somehow split among the
     instructions.  This makes linking awkward, particularly when doing
     a relocateable link in which the addend may have to be updated.
     It can be done--the MIPS ELF support does it--but it should be
     avoided when possible.

     It is possible, though somewhat awkward, to support both `Rel' and
     `Rela' relocations for a single target; `elf64-mips.c' does it by
     overriding the relocation reading and writing routines.

   * Define howto structures for all the relocation types.

   * Define a `bfd_reloc_type_lookup' routine.  This must be named
     `bfd_elfNN_bfd_reloc_type_lookup', and may be either a function or
     a macro.  It must translate a BFD relocation code into a howto
     structure.  This is normally a table lookup or a simple switch.

   * If using `Rel' relocations, define `elf_info_to_howto_rel'.  If
     using `Rela' relocations, define `elf_info_to_howto'.  Either way,
     this is a macro defined as the name of a function which takes an
     `arelent' and a `Rel' or `Rela' structure, and sets the `howto'
     field of the `arelent' based on the `Rel' or `Rela' structure.
     This is normally uses `ELFNN_R_TYPE' to get the ELF relocation
     type and uses it as an index into a table of howto structures.

   You must also add the magic number for this processor to the
`prep_headers' function in `elf.c'.

   You must also create a header file in the `include/elf' directory
called `CPU.h'.  This file should define any target specific
information which may be needed outside of the BFD code.  In particular
it should use the `START_RELOC_NUMBERS', `RELOC_NUMBER', `FAKE_RELOC',
`EMPTY_RELOC' and `END_RELOC_NUMBERS' macros to create a table mapping
the number used to indentify a relocation to a name describing that
relocation.

   While not a BFD component, you probably also want to make the
binutils program `readelf' parse your ELF objects.  For this, you need
to add code for `EM_CPU' as appropriate in `binutils/readelf.c'.


File: bfdint.info,  Node: BFD ELF processor linker,  Next: BFD ELF processor other,  Prev: BFD ELF processor required,  Up: BFD ELF processor specific support

Processor specific linker support
---------------------------------

   The linker will be much more efficient if you define a relocate
section function.  This will permit BFD to use the ELF specific linker
support.

   If you do not define a relocate section function, BFD must use the
generic linker support, which requires converting all symbols and
relocations into BFD `asymbol' and `arelent' structures.  In this case,
relocations will be handled by calling `bfd_perform_relocation', which
will use the howto structures you have defined.  *Note BFD relocation
handling::.

   In order to support linking into a different object file format,
such as S-records, `bfd_perform_relocation' must work correctly with
your howto structures, so you can't skip that step.  However, if you
define the relocate section function, then in the normal case of
linking into an ELF file the linker will not need to convert symbols
and relocations, and will be much more efficient.

   To use a relocation section function, define the macro
`elf_backend_relocate_section' as the name of a function which will
take the contents of a section, as well as relocation, symbol, and other
information, and modify the section contents according to the relocation
information.  In simple cases, this is little more than a loop over the
relocations which computes the value of each relocation and calls
`_bfd_final_link_relocate'.  The function must check for a relocateable
link, and in that case normally needs to do nothing other than adjust
the addend for relocations against a section symbol.

   The complex cases generally have to do with dynamic linker support.
GOT and PLT relocations must be handled specially, and the linker
normally arranges to set up the GOT and PLT sections while handling
relocations.  When generating a shared library, random relocations must
normally be copied into the shared library, or converted to RELATIVE
relocations when possible.


File: bfdint.info,  Node: BFD ELF processor other,  Prev: BFD ELF processor linker,  Up: BFD ELF processor specific support

Other processor specific support options
----------------------------------------

   There are many other macros which may be defined in `elfNN-CPU.c'.
These macros may be found in `elfxx-target.h'.

   Macros may be used to override some of the generic ELF target vector
functions.

   Several processor specific hook functions which may be defined as
macros.  These functions are found as function pointers in the
`elf_backend_data' structure defined in `elf-bfd.h'.  In general, a
hook function is set by defining a macro `elf_backend_NAME'.

   There are a few processor specific constants which may also be
defined.  These are again found in the `elf_backend_data' structure.

   I will not define the various functions and constants here; see the
comments in `elf-bfd.h'.

   Normally any odd characteristic of a particular ELF processor is
handled via a hook function.  For example, the special
`SHN_MIPS_SCOMMON' section number found in MIPS ELF is handled via the
hooks `section_from_bfd_section', `symbol_processing',
`add_symbol_hook', and `output_symbol_hook'.

   Dynamic linking support, which involves processor specific
relocations requiring special handling, is also implemented via hook
functions.


File: bfdint.info,  Node: BFD ELF core files,  Next: BFD ELF future,  Prev: BFD ELF processor specific support,  Up: BFD ELF support

BFD ELF core files
==================

   On native ELF Unix systems, core files are generated without any
sections.  Instead, they only have program segments.

   When BFD is used to read an ELF core file, the BFD sections will
actually represent program segments.  Since ELF program segments do not
have names, BFD will invent names like `segmentN' where N is a number.

   A single ELF program segment may include both an initialized part
and an uninitialized part.  The size of the initialized part is given
by the `p_filesz' field.  The total size of the segment is given by the
`p_memsz' field.  If `p_memsz' is larger than `p_filesz', then the
extra space is uninitialized, or, more precisely, initialized to zero.

   BFD will represent such a program segment as two different sections.
The first, named `segmentNa', will represent the initialized part of
the program segment.  The second, named `segmentNb', will represent the
uninitialized part.

   ELF core files store special information such as register values in
program segments with the type `PT_NOTE'.  BFD will attempt to
interpret the information in these segments, and will create additional
sections holding the information.  Some of this interpretation requires
information found in the host header file `sys/procfs.h', and so will
only work when BFD is built on a native system.

   BFD does not currently provide any way to create an ELF core file.
In general, BFD does not provide a way to create core files.  The way to
implement this would be to write `bfd_set_format' and
`bfd_write_contents' routines for the `bfd_core' type; see *Note BFD
target vector format::.


File: bfdint.info,  Node: BFD ELF future,  Prev: BFD ELF core files,  Up: BFD ELF support

BFD ELF future
==============

   The current dynamic linking support has too much code duplication.
While each processor has particular differences, much of the dynamic
linking support is quite similar for each processor.  The GOT and PLT
are handled in fairly similar ways, the details of -Bsymbolic linking
are generally similar, etc.  This code should be reworked to use more
generic functions, eliminating the duplication.

   Similarly, the relocation handling has too much duplication.  Many of
the `reloc_type_lookup' and `info_to_howto' functions are quite
similar.  The relocate section functions are also often quite similar,
both in the standard linker handling and the dynamic linker handling.
Many of the COFF processor specific backends share a single relocate
section function (`_bfd_coff_generic_relocate_section'), and it should
be possible to do something like this for the ELF targets as well.

   The appearance of the processor specific magic number in
`prep_headers' in `elf.c' is somewhat bogus.  It should be possible to
add support for a new processor without changing the generic support.

   The processor function hooks and constants are ad hoc and need better
documentation.

   When a linker script uses `SIZEOF_HEADERS', the ELF backend must
guess at the number of program segments which will be required, in
`get_program_header_size'.  This is because the linker calls
`bfd_sizeof_headers' before it knows all the section addresses and
sizes.  The ELF backend may later discover, when creating program
segments, that more program segments are required.  This is currently
reported as an error in `assign_file_positions_for_segments'.

   In practice this makes it difficult to use `SIZEOF_HEADERS' except
with a carefully defined linker script.  Unfortunately,
`SIZEOF_HEADERS' is required for fast program loading on a native
system, since it permits the initial code section to appear on the same
page as the program segments, saving a page read when the program starts
running.  Fortunately, native systems permit careful definition of the
linker script.  Still, ideally it would be possible to use relaxation to
compute the number of program segments.


File: bfdint.info,  Node: BFD glossary,  Next: Index,  Prev: BFD ELF support,  Up: Top

BFD glossary
************

   This is a short glossary of some BFD terms.

a.out
     The a.out object file format.  The original Unix object file
     format.  Still used on SunOS, though not Solaris.  Supports only
     three sections.

archive
     A collection of object files produced and manipulated by the `ar'
     program.

backend
     The implementation within BFD of a particular object file format.
     The set of functions which appear in a particular target vector.

BFD
     The BFD library itself.  Also, each object file, archive, or
     exectable opened by the BFD library has the type `bfd *', and is
     sometimes referred to as a bfd.

COFF
     The Common Object File Format.  Used on Unix SVR3.  Used by some
     embedded targets, although ELF is normally better.

DLL
     A shared library on Windows.

dynamic linker
     When a program linked against a shared library is run, the dynamic
     linker will locate the appropriate shared library and arrange to
     somehow include it in the running image.

dynamic object
     Another name for an ELF shared library.

ECOFF
     The Extended Common Object File Format.  Used on Alpha Digital Unix
     (formerly OSF/1), as well as Ultrix and Irix 4.  A variant of COFF.

ELF
     The Executable and Linking Format.  The object file format used on
     most modern Unix systems, including GNU/Linux, Solaris, Irix, and
     SVR4.  Also used on many embedded systems.

executable
     A program, with instructions and symbols, and perhaps dynamic
     linking information.  Normally produced by a linker.

LMA
     Load Memory Address.  This is the address at which a section will
     be loaded.  Compare with VMA, below.

NLM
     NetWare Loadable Module.  Used to describe the format of an object
     which be loaded into NetWare, which is some kind of PC based
     network server program.

object file
     A binary file including machine instructions, symbols, and
     relocation information.  Normally produced by an assembler.

object file format
     The format of an object file.  Typically object files and
     executables for a particular system are in the same format,
     although executables will not contain any relocation information.

PE
     The Portable Executable format.  This is the object file format
     used for Windows (specifically, Win32) object files.  It is based
     closely on COFF, but has a few significant differences.

PEI
     The Portable Executable Image format.  This is the object file
     format used for Windows (specifically, Win32) executables.  It is
     very similar to PE, but includes some additional header
     information.

relocations
     Information used by the linker to adjust section contents.  Also
     called relocs.

section
     Object files and executable are composed of sections.  Sections
     have optional data and optional relocation information.

shared library
     A library of functions which may be used by many executables
     without actually being linked into each executable.  There are
     several different implementations of shared libraries, each having
     slightly different features.

symbol
     Each object file and executable may have a list of symbols, often
     referred to as the symbol table.  A symbol is basically a name and
     an address.  There may also be some additional information like
     the type of symbol, although the type of a symbol is normally
     something simple like function or object, and should be confused
     with the more complex C notion of type.  Typically every global
     function and variable in a C program will have an associated
     symbol.

target vector
     A set of functions which implement support for a particular object
     file format.  The `bfd_target' structure.

Win32
     The current Windows API, implemented by Windows 95 and later and
     Windows NT 3.51 and later, but not by Windows 3.1.

XCOFF
     The eXtended Common Object File Format.  Used on AIX.  A variant of
     COFF, with a completely different symbol table implementation.

VMA
     Virtual Memory Address.  This is the address a section will have
     when an executable is run.  Compare with LMA, above.


File: bfdint.info,  Node: Index,  Prev: BFD glossary,  Up: Top

Index
*****

* Menu:

* aout-target.h:                         BFD multiple compilations.
* aoutf1.h:                              BFD multiple compilations.
* aoutx.h:                               BFD multiple compilations.
* bfd elf support:                       BFD ELF support.
* bfd generated files:                   BFD generated files.
* bfd glossary:                          BFD glossary.
* bfd internals:                         Top.
* bfd programming guidelines:            BFD guidelines.
* bfd relocation handling:               BFD relocation handling.
* bfd target vector:                     BFD target vector.
* bfd-in2.h:                             BFD generated files.
* bfd-in3.h:                             BFD generated files.
* bfd.h:                                 BFD generated files.
* BFD_JUMP_TABLE:                        BFD_JUMP_TABLE macros.
* BFD_JUMP_TABLE_ARCHIVE:                BFD target vector archive.
* BFD_JUMP_TABLE_COPY:                   BFD target vector copy.
* BFD_JUMP_TABLE_CORE:                   BFD target vector core.
* BFD_JUMP_TABLE_DYNAMIC:                BFD target vector dynamic.
* BFD_JUMP_TABLE_GENERIC:                BFD target vector generic.
* BFD_JUMP_TABLE_LINK:                   BFD target vector link.
* BFD_JUMP_TABLE_RELOCS:                 BFD target vector relocs.
* BFD_JUMP_TABLE_SYMBOLS:                BFD target vector symbols.
* BFD_JUMP_TABLE_WRITE:                  BFD target vector write.
* coffcode.h:                            BFD multiple compilations.
* coffswap.h:                            BFD multiple compilations.
* ecoffswap.h:                           BFD multiple compilations.
* elf core files:                        BFD ELF core files.
* elf support in bfd:                    BFD ELF support.
* elf32-target.h:                        BFD generated files.
* elf64-target.h:                        BFD generated files.
* elfcode.h:                             BFD multiple compilations.
* elfcore.h:                             BFD multiple compilations.
* elflink.h:                             BFD multiple compilations.
* elfxx-target.h:                        BFD multiple compilations.
* freebsd.h:                             BFD multiple compilations.
* generated files in bfd:                BFD generated files.
* glossary for bfd:                      BFD glossary.
* guidelines, bfd programming:           BFD guidelines.
* libbfd.h:                              BFD generated files.
* libcoff.h:                             BFD generated files.
* netbsd.h:                              BFD multiple compilations.
* nlm-target.h:                          BFD multiple compilations.
* nlmcode.h:                             BFD multiple compilations.
* nlmswap.h:                             BFD multiple compilations.
* peicode.h:                             BFD multiple compilations.
* programming guidelines for bfd:        BFD guidelines.
* relocations in bfd:                    BFD relocation handling.
* target vector in bfd:                  BFD target vector.
* targmatch.h:                           BFD generated files.


