START-INFO-DIR-ENTRY
* Bfd: (bfd).                   The Binary File Descriptor library.
END-INFO-DIR-ENTRY

This file documents the BFD library.

Copyright (C) 1991, 2000 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

This file documents the binary file descriptor library libbfd.

Menu

Introduction

BFD is split into two parts: the front end, and the back ends (one for each object file format).

• The front end of BFD provides the interface to the user. It manages memory and various canonical data structures. The front end also decides which back end to use and when to call back end routines.
• The back ends provide BFD its view of the real world. Each back end provides a set of calls which the BFD front end can use to maintain its canonical form. The back ends also may keep around information for their own use, for greater efficiency.

Menu

History

The name came from a conversation David Wallace was having with Richard Stallman about the library: RMS said that it would be quite hard--David said "BFD". Stallman was right, but the name stuck.

At the same time, Ready Systems wanted much the same thing, but for different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k coff.

BFD was first implemented by members of Cygnus Support; Steve Chamberlain (sac@cygnus.com), John Gilmore (gnu@cygnus.com), K. Richard Pixley (rich@cygnus.com) and David Henkel-Wallace (gumby@cygnus.com).

How To Use BFD

BFD provides a common interface to the parts of an object file for a calling application.

When an application sucessfully opens a target file (object, archive, or whatever), a pointer to an internal structure is returned. This pointer points to a structure called bfd, described in bfd.h. Our convention is to call this pointer a BFD, and instances of it within code abfd. All operations on the target object file are applied as methods to the BFD. The mapping is defined within bfd.h in a set of macros, all beginning with bfd_ to reduce namespace pollution.

For example, this sequence does what you would probably expect: return the number of sections in an object file attached to a BFD abfd.

#include "bfd.h"

unsigned int number_of_sections(abfd)
bfd *abfd;
{
  return bfd_count_sections(abfd);
}

The abstraction used within BFD is that an object file has:

• a header,
• a number of sections containing raw data (see [Sections].),
• a set of relocations (see [Relocations].), and
• some symbol information (see [Symbols].).

Also, BFDs opened for archives have the additional attribute of an index and contain subordinate BFDs. This approach is fine for a.out and coff, but loses efficiency when applied to formats such as S-records and IEEE-695.

What BFD Version 2 Can Do

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.

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.

Menu

Information Loss

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., a.out) 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. Information can be lost during canonicalization. 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.

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 a.out to b.out. When a mixture of formats is linked, the information is only lost from the files whose format differs from the destination.

The BFD canonical object-file format

files

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

sections

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.

symbols

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. ld 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 a.out, 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.

relocation level

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.

line numbers

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

BFD front end

typedef bfd

Here is the structure that defines the type bfd. It contains the major data about the file and pointers to the rest of the data.

struct _bfd
{
    /* The filename the application opened the BFD with.  */
    CONST char *filename;

    /* A pointer to the target jump table.             */
    const struct bfd_target *xvec;

    /* To avoid dragging too many header files into every file that
       includes `bfd.h', IOSTREAM has been declared as a "char
       *", and MTIME as a "long".  Their correct types, to which they
       are cast when used, are "FILE *" and "time_t".    The iostream
       is the result of an fopen on the filename.  However, if the
       BFD_IN_MEMORY flag is set, then iostream is actually a pointer
       to a bfd_in_memory struct.  */
    PTR iostream;

    /* Is the file descriptor being cached?  That is, can it be closed as
       needed, and re-opened when accessed later?  */

    boolean cacheable;

    /* Marks whether there was a default target specified when the
       BFD was opened. This is used to select which matching algorithm
       to use to choose the back end. */

    boolean target_defaulted;

    /* The caching routines use these to maintain a
       least-recently-used list of BFDs */

    struct _bfd *lru_prev, *lru_next;

    /* When a file is closed by the caching routines, BFD retains
       state information on the file here: */

    file_ptr where;

    /* and here: (``once'' means at least once) */

    boolean opened_once;

    /* Set if we have a locally maintained mtime value, rather than
       getting it from the file each time: */

    boolean mtime_set;

    /* File modified time, if mtime_set is true: */

    long mtime;

    /* Reserved for an unimplemented file locking extension.*/

    int ifd;

    /* The format which belongs to the BFD. (object, core, etc.) */

    bfd_format format;

    /* The direction the BFD was opened with*/

    enum bfd_direction {no_direction = 0,
                        read_direction = 1,
                        write_direction = 2,
                        both_direction = 3} direction;

    /* Format_specific flags*/

    flagword flags;

    /* Currently my_archive is tested before adding origin to
       anything. I believe that this can become always an add of
       origin, with origin set to 0 for non archive files.   */

    file_ptr origin;

    /* Remember when output has begun, to stop strange things
       from happening. */
    boolean output_has_begun;

    /* Pointer to linked list of sections*/
    struct sec  *sections;

    /* The number of sections */
    unsigned int section_count;

    /* Stuff only useful for object files:
       The start address. */
    bfd_vma start_address;

    /* Used for input and output*/
    unsigned int symcount;

    /* Symbol table for output BFD (with symcount entries) */
    struct symbol_cache_entry  **outsymbols;

    /* Pointer to structure which contains architecture information*/
    const struct bfd_arch_info *arch_info;

    /* Stuff only useful for archives:*/
    PTR arelt_data;
    struct _bfd *my_archive;     /* The containing archive BFD.  */
    struct _bfd *next;           /* The next BFD in the archive.  */
    struct _bfd *archive_head;   /* The first BFD in the archive.  */
    boolean has_armap;

    /* A chain of BFD structures involved in a link.  */
    struct _bfd *link_next;

    /* A field used by _bfd_generic_link_add_archive_symbols.  This will
       be used only for archive elements.  */
    int archive_pass;

    /* Used by the back end to hold private data. */

    union
      {
      struct aout_data_struct *aout_data;
      struct artdata *aout_ar_data;
      struct _oasys_data *oasys_obj_data;
      struct _oasys_ar_data *oasys_ar_data;
      struct coff_tdata *coff_obj_data;
      struct pe_tdata *pe_obj_data;
      struct xcoff_tdata *xcoff_obj_data;
      struct ecoff_tdata *ecoff_obj_data;
      struct ieee_data_struct *ieee_data;
      struct ieee_ar_data_struct *ieee_ar_data;
      struct srec_data_struct *srec_data;
      struct ihex_data_struct *ihex_data;
      struct tekhex_data_struct *tekhex_data;
      struct elf_obj_tdata *elf_obj_data;
      struct nlm_obj_tdata *nlm_obj_data;
      struct bout_data_struct *bout_data;
      struct sun_core_struct *sun_core_data;
      struct sco5_core_struct *sco5_core_data;
      struct trad_core_struct *trad_core_data;
      struct som_data_struct *som_data;
      struct hpux_core_struct *hpux_core_data;
      struct hppabsd_core_struct *hppabsd_core_data;
      struct sgi_core_struct *sgi_core_data;
      struct lynx_core_struct *lynx_core_data;
      struct osf_core_struct *osf_core_data;
      struct cisco_core_struct *cisco_core_data;
      struct versados_data_struct *versados_data;
      struct netbsd_core_struct *netbsd_core_data;
      PTR any;
      } tdata;

    /* Used by the application to hold private data*/
    PTR usrdata;

  /* Where all the allocated stuff under this BFD goes.  This is a
     struct objalloc *, but we use PTR to avoid requiring the inclusion of
     objalloc.h.  */
    PTR memory;
};

Error reporting

The easiest way to report a BFD error to the user is to use bfd_perror.

Type bfd_error_type

typedef enum bfd_error
{
  bfd_error_no_error = 0,
  bfd_error_system_call,
  bfd_error_invalid_target,
  bfd_error_wrong_format,
  bfd_error_invalid_operation,
  bfd_error_no_memory,
  bfd_error_no_symbols,
  bfd_error_no_armap,
  bfd_error_no_more_archived_files,
  bfd_error_malformed_archive,
  bfd_error_file_not_recognized,
  bfd_error_file_ambiguously_recognized,
  bfd_error_no_contents,
  bfd_error_nonrepresentable_section,
  bfd_error_no_debug_section,
  bfd_error_bad_value,
  bfd_error_file_truncated,
  bfd_error_file_too_big,
  bfd_error_invalid_error_code
} bfd_error_type;

bfd_get_error

bfd_error_type bfd_get_error (void);

Return the current BFD error condition.

bfd_set_error

void bfd_set_error (bfd_error_type error_tag);

Set the BFD error con

Menu

Memory usage

BFD does not free anything created by an application, but pointers into bfd structures become invalid on a bfd_close; for example, after a bfd_close the vector passed to bfd_canonicalize_symtab is still around, since it has been allocated by the application, but the data that it pointed to are lost.

The general rule is to not close a BFD until all operations dependent upon data from the BFD have been completed, or all the data from within the file has been copied. To help with the management of memory, there is a function (bfd_alloc_size) which returns the number of bytes in obstacks associated with the supplied BFD. This could be used to select the greediest open BFD, close it to reclaim the memory, perform some operation and reopen the BFD again, to get a fresh copy of the data structures.

Initialization

bfd_init

void bfd_init(void);

This routine must be called before any other BFD function to initialize magical internal data structures.

Sections

Sections are supported in BFD in section.c.

Menu

Section input

Each section has a name which describes the section in the outside world--for example, a.out would contain at least three sections, called .text, .data and .bss.

Names need not be unique; for example a COFF file may have several sections named .data.

Sometimes a BFD will contain more than the "natural" number of sections. A back end may attach other sections containing constructor data, or an application may add a section (using bfd_make_section) to the sections attached to an already open BFD. For example, the linker creates an extra section COMMON for each input file's BFD to hold information about common storage.

The raw data is not necessarily read in when the section descriptor is created. Some targets may leave the data in place until a bfd_get_section_contents call is made. Other back ends may read in all the data at once. For example, an S-record file has to be read once to determine the size of the data. An IEEE-695 file doesn't contain raw data in sections, but data and relocation expressions intermixed, so the data area has to be parsed to get out the data and relocations.

Section output

Any program that creates or combines sections (e.g., the assembler and linker) must use the asection fields output_section and output_offset to indicate the file sections to which each section must be written. (If the section is being created from scratch, output_section should probably point to the section itself and output_offset should probably be zero.)

The data to be written comes from input sections attached (via output_section pointers) to the output sections. The output section structure can be considered a filter for the input section: the output section determines the vma of the output data and the name, but the input section determines the offset into the output section of the data to be written.

E.g., to create a section "O", starting at 0x100, 0x123 long, containing two subsections, "A" at offset 0x0 (i.e., at vma 0x100) and "B" at offset 0x20 (i.e., at vma 0x120) the asection structures would look like:

   section name          "A"
     output_offset   0x00
     size            0x20
     output_section ----------->  section name    "O"
                             |    vma             0x100
   section name          "B" |    size            0x123
     output_offset   0x20    |
     size            0x103   |
     output_section  --------|

Link orders

A link_order knows how big it is, and which is the next link_order and where the raw data for it is; it also points to a list of relocations which apply to it.

The link_order is used by the linker to perform relaxing on final code. The compiler creates code which is as big as necessary to make it work without relaxing, and the user can select whether to relax. Sometimes relaxing takes a lot of time. The linker runs around the relocations to see if any are attached to data which can be shrunk, if so it does it on a link_order by link_order basis.

typedef asection

/* This structure is used for a comdat section, as in PE.  A comdat
   section is associated with a particular symbol.  When the linker
   sees a comdat section, it keeps only one of the sections with a
   given name and associated with a given symbol.  */

struct bfd_comdat_info
{
  /* The name of the symbol associated with a comdat section.  */
  const char *name;

  /* The local symbol table index of the symbol associated with a
     comdat section.  This is only meaningful to the object file format
     specific code; it is not an index into the list returned by
     bfd_canonicalize_symtab.  */
  long symbol;
};

typedef struct sec
{
  /* The name of the section; the name isn't a copy, the pointer is
     the same as that passed to bfd_make_section.  */

  const char *name;

  /* A unique sequence number.  */

  int id;

  /* Which section is it; 0..nth.  */

  int index;

  /* The next section in the list belonging to the BFD, or NULL.  */

  struct sec *next;

  /* The field flags contains attributes of the section. Some
     flags are read in from the object file, and some are
     synthesized from other information.  */

  flagword flags;

#define SEC_NO_FLAGS   0x000

  /* Tells the OS to allocate space for this section when loading.
     This is clear for a section containing debug information only.  */
#define SEC_ALLOC      0x001

  /* Tells the OS to load the section from the file when loading.
     This is clear for a .bss section.  */
#define SEC_LOAD       0x002

  /* The section contains data still to be relocated, so there is
     some relocation information too.  */
#define SEC_RELOC      0x004

#if 0   /* Obsolete ? */
#define SEC_BALIGN     0x008
#endif

  /* A signal to the OS that the section contains read only data.  */
#define SEC_READONLY   0x010

  /* The section contains code only.  */
#define SEC_CODE       0x020

  /* The section contains data only.  */
#define SEC_DATA       0x040

  /* The section will reside in ROM.  */
#define SEC_ROM        0x080

  /* The section contains constructor information. This section
     type is used by the linker to create lists of constructors and
     destructors used by g++. When a back end sees a symbol
     which should be used in a constructor list, it creates a new
     section for the type of name (e.g., __CTOR_LIST__), attaches
     the symbol to it, and builds a relocation. To build the lists
     of constructors, all the linker has to do is catenate all the
     sections called __CTOR_LIST__ and relocate the data
     contained within - exactly the operations it would peform on
     standard data.  */
#define SEC_CONSTRUCTOR 0x100

  /* The section is a constructor, and should be placed at the
     end of the text, data, or bss section(?).  */
#define SEC_CONSTRUCTOR_TEXT 0x1100
#define SEC_CONSTRUCTOR_DATA 0x2100
#define SEC_CONSTRUCTOR_BSS  0x3100

  /* The section has contents - a data section could be
     SEC_ALLOC | SEC_HAS_CONTENTS; a debug section could be
     SEC_HAS_CONTENTS  */
#define SEC_HAS_CONTENTS 0x200

  /* An instruction to the linker to not output the section
     even if it has information which would normally be written.  */
#define SEC_NEVER_LOAD 0x400

  /* The section is a COFF shared library section.  This flag is
     only for the linker.  If this type of section appears in
     the input file, the linker must copy it to the output file
     without changing the vma or size.  FIXME: Although this
     was originally intended to be general, it really is COFF
     specific (and the flag was renamed to indicate this).  It
     might be cleaner to have some more general mechanism to
     allow the back end to control what the linker does with
     sections.  */
#define SEC_COFF_SHARED_LIBRARY 0x800

  /* The section has GOT references.  This flag is only for the
     linker, and is currently only used by the elf32-hppa back end.
     It will be set if global offset table references were detected
     in this section, which indicate to the linker that the section
     contains PIC code, and must be handled specially when doing a
     static link.  */
#define SEC_HAS_GOT_REF 0x4000

  /* The section contains common symbols (symbols may be defined
     multiple times, the value

Symbols

Menu

Reading symbols

         long storage_needed;
         asymbol **symbol_table;
         long number_of_symbols;
         long i;

         storage_needed = bfd_get_symtab_upper_bound (abfd);

         if (storage_needed < 0)
           FAIL

         if (storage_needed == 0) {
            return ;
         }
         symbol_table = (asymbol **) xmalloc (storage_needed);
           ...
         number_of_symbols =
            bfd_canonicalize_symtab (abfd, symbol_table);

         if (number_of_symbols < 0)
           FAIL

         for (i = 0; i < number_of_symbols; i++) {
            process_symbol (symbol_table[i]);
         }

All storage for the symbols themselves is in an objalloc connected to the BFD; it is freed when the BFD is closed.

Writing symbols

       #include "bfd.h"
       main()
       {
         bfd *abfd;
         asymbol *ptrs[2];
         asymbol *new;

         abfd = bfd_openw("foo","a.out-sunos-big");
         bfd_set_format(abfd, bfd_object);
         new = bfd_make_empty_symbol(abfd);
         new->name = "dummy_symbol";
         new->section = bfd_make_section_old_way(abfd, ".text");
         new->flags = BSF_GLOBAL;
         new->value = 0x12345;

         ptrs[0] = new;
         ptrs[1] = (asymbol *)0;

         bfd_set_symtab(abfd, ptrs, 1);
         bfd_close(abfd);
       }

       ./makesym
       nm foo
       00012345 A dummy_symbol

Many formats cannot represent arbitary symbol information; for instance, the a.out object format does not allow an arbitary number of sections. A symbol pointing to a section which is not one of .text, .data or .bss cannot be described.

Mini Symbols

The bfd_read_minisymbols function will read the symbols into memory in an internal form. It will return a void * pointer to a block of memory, a symbol count, and the size of each symbol. The pointer is allocated using malloc, and should be freed by the caller when it is no longer needed.

The function bfd_minisymbol_to_symbol will take a pointer to a minisymbol, and a pointer to a structure returned by bfd_make_empty_symbol, and return a asymbol structure. The return value may or may not be the same as the value from bfd_make_empty_symbol which was passed in.

typedef asymbol

typedef struct symbol_cache_entry
{
       /* A pointer to the BFD which owns the symbol. This information
          is necessary so that a back end can work out what additional
          information (invisible to the application writer) is carried
          with the symbol.

          This field is *almost* redundant, since you can use section->owner
          instead, except that some symbols point to the global sections
          bfd_{abs,com,und}_section.  This could be fixed by making
          these globals be per-bfd (or per-target-flavor).  FIXME. */

  struct _bfd *the_bfd; /* Use bfd_asymbol_bfd(sym) to access this field. */

       /* The text of the symbol. The name is left alone, and not copied; the
          application may not alter it. */
  CONST char *name;

       /* The value of the symbol.  This really should be a union of a
          numeric value with a pointer, since some flags indicate that
          a pointer to another symbol is stored here.  */
  symvalue value;

       /* Attributes of a symbol: */

#define BSF_NO_FLAGS    0x00

       /* The symbol has local scope; static in C. The value
          is the offset into the section of the data. */
#define BSF_LOCAL      0x01

       /* The symbol has global scope; initialized data in C. The
          value is the offset into the section of the data. */
#define BSF_GLOBAL     0x02

       /* The symbol has global scope and is exported. The value is
          the offset into the section of the data. */
#define BSF_EXPORT     BSF_GLOBAL /* no real difference */

       /* A normal C symbol would be one of:
          BSF_LOCAL, BSF_FORT_COMM,  BSF_UNDEFINED or
          BSF_GLOBAL */

       /* The symbol is a debugging record. The value has an arbitary
          meaning, unless BSF_DEBUGGING_RELOC is also set.  */
#define BSF_DEBUGGING  0x08

       /* The symbol denotes a function entry point.  Used in ELF,
          perhaps others someday.  */
#define BSF_FUNCTION    0x10

       /* Used by the linker. */
#define BSF_KEEP        0x20
#define BSF_KEEP_G      0x40

       /* A weak global symbol, overridable without warnings by
          a regular global symbol of the same name.  */
#define BSF_WEAK        0x80

       /* This symbol was created to point to a section, e.g. ELF's
          STT_SECTION symbols.  */
#define BSF_SECTION_SYM 0x100

       /* The symbol used to be a common symbol, but now it is
          allocated. */
#define BSF_OLD_COMMON  0x200

       /* The default value for common data. */
#define BFD_FORT_COMM_DEFAULT_VALUE 0

       /* In some files the type of a symbol sometimes alters its
          location in an output file - ie in coff a ISFCN symbol
          which is also C_EXT symbol appears where it was
          declared and not at the end of a section.  This bit is set
          by the target BFD part to convey this information. */

#define BSF_NOT_AT_END    0x400

       /* Signal that the symbol is the label of constructor section. */
#define BSF_CONSTRUCTOR   0x800

       /* Signal that the symbol is a warning symbol.  The name is a
          warning.  The name of the next symbol is the one to warn about;
          if a reference is made to a symbol with the same name as the next
          symbol, a warning is issued by the linker. */
#define BSF_WARNING       0x1000

       /* Signal that the symbol is indirect.  This symbol is an indirect
          pointer to the symbol with the same name as the next symbol. */
#define BSF_INDIRECT      0x2000

       /* BSF_FILE marks symbols that contain a file name.  This is used
          for ELF STT_FILE symbols.  */
#define BSF_FILE          0x4000

       /* Symbol is from dynamic linking information.  */
#define BSF_DYNAMIC       0x8000

       /* The symbol denotes a data object.  Used in ELF, and perhaps
          others someday.  */
#define BSF_OBJECT        0x10000

       /*

Archives

An archive (or library) is just another BFD. It has a symbol table, although there's not much a user program will do with it.

The big difference between an archive BFD and an ordinary BFD is that the archive doesn't have sections. Instead it has a chain of BFDs that are considered its contents. These BFDs can be manipulated like any other. The BFDs contained in an archive opened for reading will all be opened for reading. You may put either input or output BFDs into an archive opened for output; they will be handled correctly when the archive is closed.

Use bfd_openr_next_archived_file to step through the contents of an archive opened for input. You don't have to read the entire archive if you don't want to! Read it until you find what you want.

Archive contents of output BFDs are chained through the next pointer in a BFD. The first one is findable through the archive_head slot of the archive. Set it with bfd_set_archive_head (q.v.). A given BFD may be in only one open output archive at a time.

As expected, the BFD archive code is more general than the archive code of any given environment. BFD archives may contain files of different formats (e.g., a.out and coff) and even different architectures. You may even place archives recursively into archives!

This can cause unexpected confusion, since some archive formats are more expressive than others. For instance, Intel COFF archives can preserve long filenames; SunOS a.out archives cannot. If you move a file from the first to the second format and back again, the filename may be truncated. Likewise, different a.out environments have different conventions as to how they truncate filenames, whether they preserve directory names in filenames, etc. When interoperating with native tools, be sure your files are homogeneous.

Beware: most of these formats do not react well to the presence of spaces in filenames. We do the best we can, but can't always handle this case due to restrictions in the format of archives. Many Unix utilities are braindead in regards to spaces and such in filenames anyway, so this shouldn't be much of a restriction.

Archives are supported in BFD in archive.c.

bfd_get_next_mapent

symindex bfd_get_next_mapent(bfd *abfd, symindex previous, carsym **sym);

Step through archive abfd's symbol table (if it has one). Successively update sym with the next symbol's information, returning that symbol's (internal) index into the symbol table.

Supply BFD_NO_MORE_SYMBOLS as the previous entry to get the first one; returns BFD_NO_MORE_SYMBOLS when you've already got the last one.

A carsym is a canonical archive symbol. The only user-visible element is its name, a null-terminated string.

bfd_set_archive_head

boolean bfd_set_archive_head(bfd *output, bfd *new_head);

Set the head of the chain of BFDs contained in the archive output to new_head.

File formats

• bfd_object

• bfd_archive

• bfd_core

bfd_check_format

boolean bfd_check_format(bfd *abfd, bfd_format format);

Verify if the file attached to the BFD abfd is compatible with the format format (i.e., one of bfd_object, bfd_archive or bfd_core).

If the BFD has been set to a specific target before the call, only the named target and format combination is checked. If the target has not been set, or has been set to default, then all the known target backends is interrogated to determine a match. If the default target matches, it is used. If not, exactly one target must recognize the file, or an error results.

The function returns true on success, otherwise false with one of the following error codes:

• bfd_error_invalid_operation - if format is not one of bfd_object, bfd_archive or bfd_core.
• bfd_error_system_call - if an error occured during a read - even some file mismatches can cause bfd_error_system_calls.
• file_not_recognised - none of the backends recognised the file format.
• bfd_error_file_ambiguously_recognized - more than one backend recognised the file format.

bfd_check_format_matches

boolean bfd_check_format_matches(bfd *abfd, bfd_format format, char ***matching);

Like bfd_check_format, except when it returns false with bfd_errno set to bfd_error_file_ambiguously_recognized. In that case, if matching is not NULL, it will be filled in with a NULL-terminated list of the names of the formats that matched, allocated with malloc. Then the user may choose a format and try again.

When done with the list that matching points to, the caller should free it.

bfd_set_format

boolean bfd_set_format(bfd *abfd, bfd_format format);

This function sets the file format of the BFD abfd to the format format. If the target set in the BFD does not support the format requested, the format is invalid, or the BFD is not open for writing, then an error occurs.

bfd_format_string

CONST char *bfd_format_string(bfd_format format);

Return a pointer to a const string invalid, object, archive, core, or unknown, depending upon the value of format.

Relocations

Relocations are maintained on a per section basis, while symbols are maintained on a per BFD basis.

All that a back end has to do to fit the BFD interface is to create a struct reloc_cache_entry for each relocation in a particular section, and fill in the right bits of the structures.

Menu

typedef arelent

typedef enum bfd_reloc_status
{
       /* No errors detected */
  bfd_reloc_ok,

       /* The relocation was performed, but there was an overflow. */
  bfd_reloc_overflow,

       /* The address to relocate was not within the section supplied. */
  bfd_reloc_outofrange,

       /* Used by special functions */
  bfd_reloc_continue,

       /* Unsupported relocation size requested. */
  bfd_reloc_notsupported,

       /* Unused */
  bfd_reloc_other,

       /* The symbol to relocate against was undefined. */
  bfd_reloc_undefined,

       /* The relocation was performed, but may not be ok - presently
          generated only when linking i960 coff files with i960 b.out
          symbols.  If this type is returned, the error_message argument
          to bfd_perform_relocation will be set.  */
  bfd_reloc_dangerous
 }
 bfd_reloc_status_type;


typedef struct reloc_cache_entry
{
       /* A pointer into the canonical table of pointers  */
  struct symbol_cache_entry **sym_ptr_ptr;

       /* offset in section */
  bfd_size_type address;

       /* addend for relocation value */
  bfd_vma addend;

       /* Pointer to how to perform the required relocation */
  reloc_howto_type *howto;

} arelent;

Here is a description of each of the fields within an arelent:

• sym_ptr_ptr

• address

• addend

        char foo[];
        main()
                {
                return foo[0x12345678];
                }

Could be compiled into:

        linkw fp,#-4
        moveb @#12345678,d0
        extbl d0
        unlk fp
        rts

This could create a reloc pointing to foo, but leave the offset in the data, something like:

RELOCATION RECORDS FOR [.text]:
offset   type      value
00000006 32        _foo

00000000 4e56 fffc          ; linkw fp,#-4
00000004 1039 1234 5678     ; moveb @#12345678,d0
0000000a 49c0               ; extbl d0
0000000c 4e5e               ; unlk fp
0000000e 4e75               ; rts

Using coff and an 88k, some instructions don't have enough space in them to represent the full address range, and pointers have to be loaded in two parts. So you'd get something like:

        or.u     r13,r0,hi16(_foo+0x12345678)
        ld.b     r2,r13,lo16(_foo+0x12345678)
        jmp      r1

This should create two relocs, both pointing to _foo, and with 0x12340000 in their addend field. The data would consist of:

RELOCATION RECORDS FOR [.text]:
offset   type      value
00000002 HVRT16    _foo+0x12340000
00000006 LVRT16    _foo+0x12340000

00000000 5da05678           ; or.u r13,r0,0x5678
00000004 1c4d5678           ; ld.b r2,r13,0x5678
00000008 f400c001           ; jmp r1

The relocation routine digs out the value from the data, adds it to the addend to get the original offset, and then adds the value of _foo. Note that all 32 bits have to be kept around somewhere, to cope with carry from bit 15 to bit 16.

One further example is the sparc and the a.out format. The sparc has a similar problem to the 88k, in that some instructions don't have room for an entire offset, but on the sparc the parts are created in odd sized lumps. The designers of the a.out format chose to not use the data within the section for storing part of the offset; all the offset is kept within the reloc. Anything in the data should be ignored.

        save %sp,-112,%sp
        sethi %hi(_foo+0x12345678),%g2
        ldsb [%g2+%lo(_foo+0x12345678)],%i0
        ret
        restore

Both relocs contain a pointer to foo, and the offsets contain junk.

RELOCATION RECORDS FOR [.text]:
offset   type      value
00000004 HI22      _foo+0x12345678
00000008 LO10      _foo+0x12345678

00000000 9de3bf90     ; save %sp,-112,%sp
00000004 05000000     ; sethi %hi(_foo+0),%g2
00000008 f048a000     ; ldsb [%g2+%lo(_foo+0)],%i0
0000000c 81c7e008     ; ret
00000010 81e80000     ; restore

• howto

enum complain_overflow

enum complain_overflow
{
       /* Do not complain on overflow. */
  complain_overflow_dont,

       /* Complain if the bitfield overflows, whether it is considered
          as signed or unsigned. */
  complain_overflow_bitfield,

       /* Complain if the value overflows when considered as signed
          number. */
  complain_overflow_signed,

       /* Complain if the value overflows when considered as an
          unsigned number. */
  complain_overflow_unsigned
};

reloc_howto_type

struct symbol_cache_entry;             /* Forward declaration */

struct reloc_howto_struct
{
       /*  The type field has mainly a documentary use - the back end can
           do what it wants with it, though normally the back end's
           external idea of what a reloc number is stored
           in this field. For example, a PC relative word relocation
           in a coff environment has the type 023 - because that's
           what the outside world calls a R_PCRWORD reloc. */
  unsigned int type;

       /*  The value the final relocation is shifted right by. This drops
           unwanted data from the relocation.  */
  unsigned int rightshift;

       /*  The size of the item to be relocated.  This is *not* a
           power-of-two measure.  To get the number of bytes operated
           on by a type of relocation, use bfd_get_reloc_size.  */
  int size;

       /*  The number of bits in the item to be relocated.  This is used
           when doing overflow checking.  */
  unsigned int bitsize;

       /*  Notes that the relocation is

Core files

These are functions pertaining to core files.

bfd_core_file_failing_command

CONST char *bfd_core_file_failing_command(bfd *abfd);

Return a read-only string explaining which program was running when it failed and produced the core file abfd.

bfd_core_file_failing_signal

int bfd_core_file_failing_signal(bfd *abfd);

Returns the signal number which caused the core dump which generated the file the BFD abfd is attached to.

core_file_matches_executable_p

boolean core_file_matches_executable_p
   (bfd *core_bfd, bfd *exec_bfd);

Return true if the core file attached to core_bfd was generated by a run of the executable file attached to exec_bfd, false otherwise.

Targets

Each port of BFD to a different machine requries the creation of a target back end. All the back end provides to the root part of BFD is a structure containing pointers to functions which perform certain low level operations on files. BFD translates the applications's requests through a pointer into calls to the back end routines.

When a file is opened with bfd_openr, its format and target are unknown. BFD uses various mechanisms to determine how to interpret the file. The operations performed are:

• Create a BFD by calling the internal routine _bfd_new_bfd, then call bfd_find_target with the target string supplied to bfd_openr and the new BFD pointer.
• If a null target string was provided to bfd_find_target, look up the environment variable GNUTARGET and use that as the target string.
• If the target string is still NULL, or the target string is default, then use the first item in the target vector as the target type, and set target_defaulted in the BFD to cause bfd_check_format to loop through all the targets. See [bfd_target]. See [Formats].
• Otherwise, inspect the elements in the target vector one by one, until a match on target name is found. When found, use it.
• Otherwise return the error bfd_error_invalid_target to bfd_openr.
• bfd_openr attempts to open the file using bfd_open_file, and returns the BFD.

Menu

bfd_target

This structure contains everything that BFD knows about a target. It includes things like its byte order, name, and which routines to call to do various operations.

Every BFD points to a target structure with its xvec member.

The macros below are used to dispatch to functions through the bfd_target vector. They are used in a number of macros further down in bfd.h, and are also used when calling various routines by hand inside the BFD implementation. The arglist argument must be parenthesized; it contains all the arguments to the called function.

They make the documentation (more) unpleasant to read, so if someone wants to fix this and not break the above, please do.

#define BFD_SEND(bfd, message, arglist) \
               ((*((bfd)->xvec->message)) arglist)

#ifdef DEBUG_BFD_SEND
#undef BFD_SEND
#define BFD_SEND(bfd, message, arglist) \
  (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
    ((*((bfd)->xvec->message)) arglist) : \
    (bfd_assert (__FILE__,__LINE__), NULL))
#endif

#define BFD_SEND_FMT(bfd, message, arglist) \
            (((bfd)->xvec->message[(int) ((bfd)->format)]) arglist)

#ifdef DEBUG_BFD_SEND
#undef BFD_SEND_FMT
#define BFD_SEND_FMT(bfd, message, arglist) \
  (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
   (((bfd)->xvec->message[(int) ((bfd)->format)]) arglist) : \
   (bfd_assert (__FILE__,__LINE__), NULL))
#endif

FIXME, these names should be rationalised with the names of the entry points which call them. Too bad we can't have one macro to define them both!

enum bfd_flavour {
  bfd_target_unknown_flavour,
  bfd_target_aout_flavour,
  bfd_target_coff_flavour,
  bfd_target_ecoff_flavour,
  bfd_target_xcoff_flavour,
  bfd_target_elf_flavour,
  bfd_target_ieee_flavour,
  bfd_target_nlm_flavour,
  bfd_target_oasys_flavour,
  bfd_target_tekhex_flavour,
  bfd_target_srec_flavour,
  bfd_target_ihex_flavour,
  bfd_target_som_flavour,
  bfd_target_os9k_flavour,
  bfd_target_versados_flavour,
  bfd_target_msdos_flavour,
  bfd_target_ovax_flavour,
  bfd_target_evax_flavour
};

enum bfd_endian { BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN };

/* Forward declaration.  */
typedef struct bfd_link_info _bfd_link_info;

typedef struct bfd_target
{

  char *name;

  enum bfd_flavour flavour;

  enum bfd_endian byteorder;

  enum bfd_endian header_byteorder;

  flagword object_flags;

  flagword section_flags;

  char symbol_leading_char;

  char ar_pad_char;

  unsigned short ar_max_namelen;

  bfd_vma      (*bfd_getx64) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_getx_signed_64) PARAMS ((const bfd_byte *));
  void         (*bfd_putx64) PARAMS ((bfd_vma, bfd_byte *));
  bfd_vma      (*bfd_getx32) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_getx_signed_32) PARAMS ((const bfd_byte *));
  void         (*bfd_putx32) PARAMS ((bfd_vma, bfd_byte *));
  bfd_vma      (*bfd_getx16) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_getx_signed_16) PARAMS ((const bfd_byte *));
  void         (*bfd_putx16) PARAMS ((bfd_vma, bfd_byte *));

  bfd_vma      (*bfd_h_getx64) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_h_getx_signed_64) PARAMS ((const bfd_byte *));
  void         (*bfd_h_putx64) PARAMS ((bfd_vma, bfd_byte *));
  bfd_vma      (*bfd_h_getx32) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_h_getx_signed_32) PARAMS ((const bfd_byte *));
  void         (*bfd_h_putx32) PARAMS ((bfd_vma, bfd_byte *));
  bfd_vma      (*bfd_h_getx16) PARAMS ((const bfd_byte *));
  bfd_signed_vma (*bfd_h_getx_signed_16) PARAMS ((const bfd_byte *));
  void         (*bfd_h_putx16) PARAMS ((bfd_vma, bfd_byte *));

Check the format of a file being read. Return a bfd_target * or zero.

  const struct bfd_target *(*_bfd_check_format[bfd_type_end]) PARAMS ((bfd *));

  boolean             (*_bfd_set_format[bfd_type_end]) PARAMS ((bfd *));

  boolean             (*_bfd_write_contents[bfd_type_end]) PARAMS ((bfd *));

  /* Generic entry points.  */
#define BFD_JUMP_TABLE_GENERIC(NAME)\
CAT(NAME,_close_and_cleanup),\
CAT(NAME,_bfd_free_cached_info),\
CAT(NAME,_new_section_hook),\
CAT(NAME,_get_section_contents),\
CAT(NAME,_get_section_contents_in_window)

  /* Called when the BFD is being closed to do any necessary cleanup.  */
  boolean       (*_close_and_cleanup) PARAMS ((bfd *));
  /* Ask the BFD to free all cached information.  */
  boolean (*_bfd_free_cached_info) PARAMS ((bfd *));
  /* Called when a new section is created.  */
  boolean       (*_new_section_hook) PARAMS ((bfd *, sec_ptr));
  /* Read the contents of a section.  */
  boolean       (*_bfd_get_section_contents) PARAMS ((bfd *, sec_ptr, PTR,
                                            file_ptr, bfd_size_type));
  boolean       (*_bfd_get_section_contents_in_window)
                          PARAMS ((bfd *, sec_ptr, bfd_window *,
                                   file_ptr, bfd_size_type));

  /* Entry points to copy private data.  */
#define BFD_JUMP_TABLE_COPY(NAME)\
CAT(NAME,_bfd_copy_private_bfd_data),\
CAT(NAME,_bfd_merge_private_bfd_data),\
CAT(NAME,_bfd_copy_private_section_data),\
CAT(NAME,_bfd_copy_private_symbol_data),\

Architectures

Pointers to structures can be requested independently of a BFD so that an architecture's information can be interrogated without access to an open BFD.

The architecture information is provided by each architecture package. The set of default architectures is selected by the macro SELECT_ARCHITECTURES. This is normally set up in the config/target.mt file of your choice. If the name is not defined, then all the architectures supported are included.

When BFD starts up, all the architectures are called with an initialize method. It is up to the architecture back end to insert as many items into the list of architectures as it wants to; generally this would be one for each machine and one for the default case (an item with a machine field of 0).

BFD's idea of an architecture is implemented in archures.c.

bfd_architecture

This enum gives the object file's CPU architecture, in a global sense--i.e., what processor family does it belong to? Another field indicates which processor within the family is in use. The machine gives a number which distinguishes different versions of the architecture, containing, for example, 2 and 3 for Intel i960 KA and i960 KB, and 68020 and 68030 for Motorola 68020 and 68030.

enum bfd_architecture
{
  bfd_arch_unknown,   /* File arch not known */
  bfd_arch_obscure,   /* Arch known, not one of these */
  bfd_arch_m68k,      /* Motorola 68xxx */
#define bfd_mach_m68000 1
#define bfd_mach_m68008 2
#define bfd_mach_m68010 3
#define bfd_mach_m68020 4
#define bfd_mach_m68030 5
#define bfd_mach_m68040 6
#define bfd_mach_m68060 7
#define bfd_mach_cpu32  8
  bfd_arch_vax,       /* DEC Vax */
  bfd_arch_i960,      /* Intel 960 */
    /* The order of the following is important.
       lower number indicates a machine type that
       only accepts a subset of the instructions
       available to machines with higher numbers.
       The exception is the "ca", which is
       incompatible with all other machines except
       "core". */

#define bfd_mach_i960_core      1
#define bfd_mach_i960_ka_sa     2
#define bfd_mach_i960_kb_sb     3
#define bfd_mach_i960_mc        4
#define bfd_mach_i960_xa        5
#define bfd_mach_i960_ca        6
#define bfd_mach_i960_jx        7
#define bfd_mach_i960_hx        8

  bfd_arch_a29k,      /* AMD 29000 */
  bfd_arch_sparc,     /* SPARC */
#define bfd_mach_sparc                 1
/* The difference between v8plus and v9 is that v9 is a true 64 bit env.  */
#define bfd_mach_sparc_sparclet        2
#define bfd_mach_sparc_sparclite       3
#define bfd_mach_sparc_v8plus          4
#define bfd_mach_sparc_v8plusa         5 /* with ultrasparc add'ns */
#define bfd_mach_sparc_sparclite_le    6
#define bfd_mach_sparc_v9              7
#define bfd_mach_sparc_v9a             8 /* with ultrasparc add'ns */
#define bfd_mach_sparc_v8plusb         9 /* with cheetah add'ns */
#define bfd_mach_sparc_v9b             10 /* with cheetah add'ns */
/* Nonzero if MACH has the v9 instruction set.  */
#define bfd_mach_sparc_v9_p(mach) \
  ((mach) >= bfd_mach_sparc_v8plus && (mach) <= bfd_mach_sparc_v9b \
   && (mach) != bfd_mach_sparc_sparclite_le)
  bfd_arch_mips,      /* MIPS Rxxxx */
#define bfd_mach_mips3000              3000
#define bfd_mach_mips3900              3900
#define bfd_mach_mips4000              4000
#define bfd_mach_mips4010              4010
#define bfd_mach_mips4100              4100
#define bfd_mach_mips4111              4111
#define bfd_mach_mips4300              4300
#define bfd_mach_mips4400              4400
#define bfd_mach_mips4600              4600
#define bfd_mach_mips4650              4650
#define bfd_mach_mips5000              5000
#define bfd_mach_mips6000              6000
#define bfd_mach_mips8000              8000
#define bfd_mach_mips10000             10000
#define bfd_mach_mips16                16
#define bfd_mach_mips32                32
#define bfd_mach_mips32_4k             3204113 /* 32, 04, octal 'K' */
#define bfd_mach_mips5                 5
#define bfd_mach_mips64                64
#define bfd_mach_mips_sb1              12310201 /* octal 'SB', 01 */
  bfd_arch_i386,      /* Intel 386 */
#define bfd_mach_i386_i386 0
#define bfd_mach_i386_i8086 1
#define bfd_mach_i386_i386_intel_syntax 2
#define bfd_mach_x86_64 3
#define bfd_mach_x86_64_intel_syntax 4
  bfd_arch_we32k,     /* AT&T WE32xxx */
  bfd_arch_tahoe,     /* CCI/Harris Tahoe */
  bfd_arch_i860,      /* Intel 860 */
  bfd_arch_i370,      /* IBM 360/370 Mainframes */
  bfd_arch_romp,      /* IBM ROMP PC/RT */
  bfd_arch_alliant,   /* Alliant */
  bfd_arch_convex,    /* Convex */
  bfd_arch_m88k,      /* Motorola 88xxx */
  bfd_arch_pyramid,   /* Pyramid Technology */
  bfd_arch_h8300,     /* Hitachi H8/300 */
#define bfd_mach_h8300   1
#define bfd_mach_h8300h  2
#define bfd_mach_h8300s  3
  bfd_arch_powerpc,   /* PowerPC */
#define bfd_mach_ppc           0
#define bfd_mach_ppc_403       403
#define bfd_mach_ppc_403gc     4030
#define bfd_mach_ppc_505       505
#define bfd_mach_ppc_601       601
#define bfd_mach_ppc_602       602
#define bfd_mach_ppc_603       603
#define bfd_mach_ppc_ec603e    6031
#define bfd_mach_ppc_604       604
#define bfd_mach_ppc_620       620
#define bfd_mach_ppc_630       630
#define bfd_mach_ppc_750       750
#define bfd_mach_ppc_860       860
#define bfd_mach_ppc_a35       35
#define bfd_mach_ppc_rs64ii    642
#define bfd_mach_ppc_rs64iii   643
#define bfd_mach_ppc_7400      7400
  bfd_arch_rs6000,    /* IBM RS/6000 */
#define bfd_mach_rs6k          0
#define bfd_mach_rs6k_rs1      6001
#define bfd_mach_rs6k_rsc      6003
#define bfd_mach_rs6k_rs2      6002
  bfd_arch_hppa,      /* HP PA RISC */
  bfd_arch_d10v,      /* Mitsubishi D10V */
#define bfd_mach_d10v          0
#define bfd_mach_d10v_ts2      2
#define bfd_mach_d10v_ts3      3
  bfd_arch_d30v,      /* Mitsubishi D30V */
  bfd_arch_m68hc11,   /* Motorola 68HC11 */
  bfd_arch_m68hc12,   /* Motorola 68HC12 */
  bfd_arch_z8k,       /* Zilog Z8000 */
#define bfd_mach_z8001         1
#define bfd_mach_z8002         2
  bfd_arch_h8500,     /* Hitachi H8/500 */
  bfd_arch_sh,        /* Hitachi SH */
#define bfd_mach_sh            0
#define bfd_mach_sh2        0x20
#define bfd_mach_sh_dsp     0x2d
#define bfd_mach_sh3        0x30
#define bfd_mach_sh3_dsp    0x3d
#define bfd_mach_sh3e       0x3e
#define bfd_mach_sh4        0x40
  bfd_arch_alpha,     /* Dec Alpha */
#define bfd_mach_alpha_ev4  0x10
#define bfd_mach_alpha_ev5  0x20
#define bfd_mach_alpha_ev6  0x30
  bfd_arch_arm,       /* Advanced Risc Machines ARM */
#define bfd_mach_arm_2         1
#define bfd_mach_arm_2a        2
#define bfd_mach_arm_3         3
#define bfd_mach_arm_3M        4
#define bfd_mach_arm_4         5
#define bfd_mach_arm_4T        6
#define bfd_mach_arm_5         7
#define bfd_mach_arm_5T        8
#define bfd_mach_arm_5TE       9
#define bfd_mach_arm_XScale    10
  bfd_arch_ns32k,     /* National Semiconductors ns32000 */
  bfd_arch_w65,       /* WDC 65816 */
  bfd_arch_tic30,     /* Texas Instruments TMS320C30 */
  bfd_arch_tic54x,    /* Texas Instruments TMS320C54X */
  bfd_arch_tic80,     /* TI TMS320c80 (MVP) */
  bfd_arch_v850,      /* NEC V850 */
#define bfd_mach_v850          0
#define bfd_mach_v850e         'E'
#define bfd_mach_v850ea        'A'
  bfd_arch_arc,       /* ARC Cores */
#define bfd_mach_arc_5         0
#define bfd_mach_arc_6         1
#define bfd_mach_arc_7         2
#define bfd_mach_arc_8         3
  bfd_arch_m32r,      /* Mitsubishi M32R/D */
#define bfd_mach_m32r          0 /* backwards compatibility */
#define bfd_mach_m32rx         'x'
  bfd_arch_mn10200,   /* Matsushita MN10200 */
  bfd_arch_mn10300,   /* Matsushita MN10300 */
#define bfd_mach_mn10300               300
#define bfd_mach_am33          330
  bfd_arch_fr30,
#define bfd_mach_fr30          0x46523330
  bfd_arch_mcore,
  bfd_arch_ia64,      /* HP/Intel ia64 */
#define bfd_mach_ia64_elf64    0
#define bfd_mach_ia64_elf32    1
  bfd_arch_pj,
  bfd_arch_avr,       /* Atmel AVR microcontrollers */
#define bfd_mach_avr1          1
#define bfd_mach_avr2          2
#define bfd_mach_avr3          3
#define bfd_mach_avr4          4
#define bfd_mach_avr5          5
  bfd_arch_cris,      /* Axis CRIS */
  bfd_arch_last
  };

bfd_arch_info

This structure contains information on architectures for use within BFD.

typedef struct bfd_arch_info
{
  int bits_per_word;
  int bits_per_address;
  int bits_per_byte;
  enum bfd_architecture arch;
  unsigned long mach;
  const char *arch_name;
  const char *printable_name;
  unsigned int section_align_power;
  /* True if this is the default machine for the architecture.  */
  boolean the_default;
  const struct bfd_arch_info * (*compatible)
       PARAMS ((const struct bfd_arch_info *a,
                const struct bfd_arch_info *b));

  boolean

Opening and closing BFDs

bfd_openr

bfd *bfd_openr(CONST char *filename, CONST char *target);

Open the file filename (using fopen) with the target target. Return a pointer to the created BFD.

Calls bfd_find_target, so target is interpreted as by that function.

If NULL is returned then an error has occured. Possible errors are bfd_error_no_memory, bfd_error_invalid_target or system_call error.

bfd_fdopenr

bfd *bfd_fdopenr(CONST char *filename, CONST char *target, int fd);

When the file is later bfd_closed, the file descriptor will be closed.

If the caller desires that this file descriptor be cached by BFD (opened as needed, closed as needed to free descriptors for other opens), with the supplied fd used as an initial file descriptor (but subject to closure at any time), call bfd_set_cacheable(bfd, 1) on the returned BFD. The default is to assume no cacheing; the file descriptor will remain open until bfd_close, and will not be affected by BFD operations on other files.

Possible errors are bfd_error_no_memory, bfd_error_invalid_target and bfd_error_system_call.

bfd_openstreamr

bfd *bfd_openstreamr(const char *, const char *, PTR);

Open a BFD for read access on an existing stdio stream. When the BFD is passed to bfd_close, the stream will be closed.

bfd_openw

bfd *bfd_openw(CONST char *filename, CONST char *target);

Create a BFD, associated with file filename, using the file format target, and return a pointer to it.

Possible errors are bfd_error_system_call, bfd_error_no_memory, bfd_error_invalid_target.

bfd_close

boolean bfd_close(bfd *abfd);

Close a BFD. If the BFD was open for writing, then pending operations are completed and the file written out and closed. If the c

Internal functions

These routines are used within BFD. They are not intended for export, but are documented here for completeness.

File caching

BFD_CACHE_MAX_OPEN macro

The maximum number of files which the cache will keep open at one time.

#define BFD_CACHE_MAX_OPEN 10

bfd_last_cache

extern bfd *bfd_last_cache;

Zero, or a pointer to the topmost BFD on the chain. This is used by the bfd_cache_lookup macro in libbfd.h to determine when it can avoid a function call.

bfd_cache_lookup

Check to see if the required BFD is the same as the last one looked up. If so, then it can use the stream in the BFD with impunity, since it can't have changed since the last lookup; otherwise, it has to perform the complicated lookup function.

#define bfd_cache_lookup(x) \
    ((x)==bfd_last_cache? \
      (FILE*) (bfd_last_cache->iostream): \
       bfd_cache_lookup_worker(x))

bfd_cache_init

boolean bfd_cache_init (bfd *abfd);

Add a newly opened BFD to the cache.

bfd_cache_close

boolean bfd_cache_close (bfd *abfd);

Remove the BFD abfd from the cache. If the attached file is open, then close it too. Returns
false is returned if closing the file fails, true is returned if all is well.

bfd_open_file

FILE* bfd_open_file(bfd *abfd);

Call the OS to open a file for abfd. Return the FILE * (possibly NULL) that results from this operation. Set up the BFD so that future accesses know the file is open. If the FILE * returned is NULL, then it won't have been put in the cache, so it won't have to be removed from it.

bfd_cache_lookup_worker

FILE *bfd_cache_lookup_worker(bfd *abfd);

Called when the macro bfd_cache_lookup fails to find a quick answer. Find a file descriptor for abfd. If necessary, it open it. If there are already more than BFD_CACHE_MAX_OPEN files open, it tries to close one first, to avoid running out of file descriptors.

Linker Functions

The first routine creates a hash table used by the other routines. The second routine adds the symbols from an object file to the hash table. The third routine takes all the object files and links them together to create the output file. These routines are designed so that the linker proper does not need to know anything about the symbols in the object files that it is linking. The linker merely arranges the sections as directed by the linker script and lets BFD handle the details of symbols and relocs.

The second routine and third routines are passed a pointer to a struct bfd_link_info structure (defined in bfdlink.h) which holds information relevant to the link, including the linker hash table (which was created by the first routine) and a set of callback functions to the linker proper.

The generic linker routines are in linker.c, and use the header file genlink.h. As of this writing, the only back ends which have implemented versions of these routines are a.out (in aoutx.h) and ECOFF (in ecoff.c). The a.out routines are used as examples throughout this section.

Menu

Creating a linker hash table

The _bfd_link_hash_table_create entry point must allocate and initialize an instance of the desired hash table. If the back end does not require any additional information to be stored with the entries in the hash table, the entry point may simply create a struct bfd_link_hash_table. Most likely, however, some additional information will be needed.

For example, with each entry in the hash table the a.out linker keeps the index the symbol has in the final output file (this index number is used so that when doing a relocateable link the symbol index used in the output file can be quickly filled in when copying over a reloc). The a.out linker code defines the required structures and functions for a hash table derived from struct bfd_link_hash_table. The a.out linker hash table is created by the function NAME(aout,link_hash_table_create); it simply allocates space for the hash table, initializes it, and returns a pointer to it.

When writing the linker routines for a new back end, you will generally not know exactly which fields will be required until you have finished. You should simply create a new hash table which defines no additional fields, and then simply add fields as they become necessary.

Adding symbols to the hash table

The a.out version of this entry point is NAME(aout,link_add_symbols).

Menu

Differing file formats

Sometimes the _bfd_link_add_symbols function must store some information in the hash table entry to be used by the _bfd_final_link function. In such a case the creator field of the hash table must be checked to make sure that the hash table was created by an object file of the same format.

The _bfd_final_link routine must be prepared to handle a hash entry without any extra information added by the _bfd_link_add_symbols function. A hash entry without extra information will also occur when the linker script directs the linker to create a symbol. Note that, regardless of how a hash table entry is added, all the fields will be initialized to some sort of null value by the hash table entry initialization function.

See ecoff_link_add_externals for an example of how to check the creator field before saving information (in this case, the ECOFF external symbol debugging information) in a hash table entry.

Adding symbols from an object file

The _bfd_link_add_symbols routine should not use bfd_canonicalize_symtab to read the symbols. The point of providing this routine is to avoid the overhead of converting the symbols into generic asymbol structures. _bfd_generic_link_add_one_symbol handles the details of combining common symbols, warning about multiple definitions, and so forth. It takes arguments which describe the symbol to add, notably symbol flags, a section, and an offset. The symbol flags include such things as BSF_WEAK or BSF_INDIRECT. The section is a section in the object file, or something like bfd_und_section_ptr for an undefined symbol or bfd_com_section_ptr for a common symbol.

If the _bfd_final_link routine is also going to need to read the symbol information, the _bfd_link_add_symbols routine should save it somewhere attached to the object file BFD. However, the information should only be saved if the keep_memory field of the info argument is true, so that the -no-keep-memory linker switch is effective.

The a.out function which adds symbols from an object file is aout_link_add_object_symbols, and most of the interesting work is in aout_link_add_symbols. The latter saves pointers to the hash tables entries created by _bfd_generic_link_add_one_symbol indexed by symbol number, so that the _bfd_final_link routine does not have to call the hash table lookup routine to locate the entry.

Adding symbols from an archive

Hash Tables

The basic hash table does not permit any data to be stored with a string. However, a hash table is designed to present a base class from which other types of hash tables may be derived. These derived types may store additional information with the string. Hash tables were implemented in this way, rather than simply providing a data pointer in a hash table entry, because they were designed for use by the linker back ends. The linker may create thousands of hash table entries, and the overhead of allocating private data and storing and following pointers becomes noticeable.

The basic hash table code is in hash.c.

Menu

Creating and freeing a hash table

The function bfd_hash_table_init take as an argument a function to use to create new entries. For a basic hash table, use the function bfd_hash_newfunc. See [Deriving a New Hash Table Type], for why you would want to use a different value for this argument. bfd_hash_table_init will create an objalloc which will be used to allocate new entries. You may allocate memory on this objalloc using bfd_hash_allocate.

Use bfd_hash_table_free to free up all the memory that has been allocated for a hash table. This will not free up the struct bfd_hash_table itself, which you must provide.

Looking up or entering a string

If the create argument is false, bfd_hash_lookup will look up a string. If the string is found, it will returns a pointer to a struct bfd_hash_entry. If the string is not found in the table bfd_hash_lookup will return NULL. You should not modify any of the fields in the returns struct bfd_hash_entry.

If the create argument is true, the string will be entered into the hash table if it is not already there. Either way a pointer to a struct bfd_hash_entry will be returned, either to the existing structure or to a newly created one. In this case, a NULL return means that an error occurred.

If the create argument is true, and a new entry is created, the copy argument is used to decide whether to copy the string onto the hash table objalloc or not. If copy is passed as false, you must be careful not to deallocate or modify the string as long as the hash table exists.

Traversing a hash table

Deriving a new hash table type

Since C is not an object oriented language, creating a derived hash table requires sticking together some boilerplate routines with a few differences specific to the type of hash table you want to create.

An example of a derived hash table is the linker hash table. The structures for this are defined in bfdlink.h. The functions are in linker.c.

You may also derive a hash table from an already derived hash table. For example, the a.out linker backend code uses a hash table derived from the linker hash table.

Menu

Define the derived structures

The first field in the structure for an entry in the hash table must be of the type used for an entry in the hash table you are deriving from. If you are deriving from a basic hash table this is struct bfd_hash_entry, which is defined in bfd.h. The first field in the structure for the hash table itself must be of the type of the hash table you are deriving from itself. If you are deriving from a basic hash table, this is struct bfd_hash_table.

For example, the linker hash table defines struct bfd_link_hash_entry (in bfdlink.h). The first field, root, is of type struct bfd_hash_entry. Similarly, the first field in struct bfd_link_hash_table, table, is of type struct bfd_hash_table.

Write the derived creation routine

In order to permit other hash tables to be derived from the hash table you are creating, this routine must be written in a standard way.

The first argument to the creation routine is a pointer to a hash table entry. This may be NULL, in which case the routine should allocate the right amount of space. Otherwise the space has already been allocated by a hash table type derived from this one.

After allocating space, the creation routine must call the creation routine of the hash table type it is derived from, passing in a pointer to the space it just allocated. This will initialize any fields used by the base hash table.

Finally the creation routine must initialize any local fields for the new hash table type.

Here is a boilerplate example of a creation routine. function_name is the name of the routine. entry_type is the type of an entry in the hash table you are creating. base_newfunc is the name of the creation routine of the hash table type your hash table is derived from.

struct bfd_hash_entry *
function_name (entry, table, string)
     struct bfd_hash_entry *entry;
     struct bfd_hash_table *table;
     const char *string;
{
  struct entry_type *ret = (entry_type *) entry;

 /* Allocate the structure if it has not already been allocated by a
    derived class.  */
  if (ret == (entry_type *) NULL)
    {
      ret = ((entry_type *)
             bfd_hash_allocate (table, sizeof (entry_type)));
      if (ret == (entry_type *) NULL)
        return NULL;
    }

 /* Call the allocation method of the base class.  */
  ret = ((entry_type *)
        base_newfunc ((struct bfd_hash_entry *) ret, table, string));

 /* Initialize the local fields here.  */

  return (struct bfd_hash_entry *) ret;
}

The creation routine for the

BFD back ends

Menu

All of BFD lives in one directory.

a.out backends

BFD supports a number of different flavours of a.out format, though the major differences are only the sizes of the structures on disk, and the shape of the relocation information.

The support is split into a basic support file aoutx.h and other files which derive functions from the base. One derivation file is aoutf1.h (for a.out flavour 1), and adds to the basic a.out functions support for sun3, sun4, 386 and 29k a.out files, to create a target jump vector for a specific target.

This information is further split out into more specific files for each machine, including sunos.c for sun3 and sun4, newsos3.c for the Sony NEWS, and demo64.c for a demonstration of a 64 bit a.out format.

The base file aoutx.h defines general mechanisms for reading and writing records to and from disk and various other methods which BFD requires. It is included by aout32.c and aout64.c to form the names aout_32_swap_exec_header_in, aout_64_swap_exec_header_in, etc.

As an example, this is what goes on to make the back end for a sun4, from aout32.c:

       #define ARCH_SIZE 32
       #include "aoutx.h"

Which exports names:

       ...
       aout_32_canonicalize_reloc
       aout_32_find_nearest_line
       aout_32_get_lineno
       aout_32_get_reloc_upper_bound
       ...

from sunos.c:

       #define TARGET_NAME "a.out-sunos-big"
       #define VECNAME    sunos_big_vec
       #include "aoutf1.h"

requires all the names from aout32.c, and produces the jump vector

       sunos_big_vec

The file host-aout.c is a special case. It is for a large set of hosts that use "more or less standard" a.out files, and for which cross-debugging is not interesting. It uses the standard 32-bit a.out support routines, but determines the file offsets and addresses of the text, data, and BSS sections, the machine architecture and machine type, and the entry point address, in a host-dependent manner. Once these values have been determined, generic code is used to handle the object file.

When porting it to run on a new system, you must supply:

        HOST_PAGE_SIZE
        HOST_SEGMENT_SIZE
        HOST_MACHINE_ARCH       (optional)
        HOST_MACHINE_MACHINE    (optional)
        HOST_TEXT_START_ADDR
        HOST_STACK_END_ADDR

in the file ../include/sys/h-XXX.h (for your host). These values, plus the structures and macros defined in a.out.h on your host system, will produce a BFD target that will access ordinary a.out files on your host. To configure a new machine to use host-aout.c, specify:

       TDEFAULTS = -DDEFAULT_VECTOR=host_aout_big_vec
       TDEPFILES= host-aout.o trad-core.o

in the config/XXX.mt file, and modify configure.in to use the XXX.mt file (by setting "bfd_target=XXX") when your configuration is selected.

Relocations

The file aoutx.h provides for both the standard and extended forms of a.out relocation records.

The standard records contain only an address, a symbol index, and a type field. The extended records (used on 29ks and sparcs) also have a full integer for an addend.

coff backends

Coff in all its varieties is implemented with a few common files and a number of implementation specific files. For example, The 88k bcs coff format is implemented in the file coff-m88k.c. This file #includes coff/m88k.h which defines the external structure of the coff format for the 88k, and coff/internal.h which defines the internal structure. coff-m88k.c also defines the relocations used by the 88k format See [Relocations].

The Intel i960 processor version of coff is implemented in coff-i960.c. This file has the same structure as coff-m88k.c, except that it includes coff/i960.h rather than coff-m88k.h.

Porting to a new version of coff

You can verify that your new BFD backend works quite simply by building objdump from the binutils directory, and making sure that its version of what's going on and your host system's idea (assuming it has the pretty standard coff dump utility, usually called att-dump or just dump) are the same. Then clean up your code, and send what you've done to Cygnus. Then your stuff will be in the next release, and you won't have to keep integrating it.

How the coff backend works

File layout

The generic routines are in coffgen.c. These routines work for any Coff target. They use some hooks into the target specific code; the hooks are in a bfd_coff_backend_data structure, one of which exists for each target.

The essentially similar target-specific routines are in coffcode.h. This header file includes executable C code. The various Coff targets first include the appropriate Coff header file, make any special defines that are needed, and then include coffcode.h.

Some of the Coff targets then also have additional routines in the target source file itself.

For example, coff-i960.c includes coff/internal.h and coff/i960.h. It then defines a few constants, such as I960, and includes coffcode.h. Since the i960 has complex relocation types, coff-i960.c also includes some code to manipulate the i960 relocs. This code is not in coffcode.h because it would not be used by any other target.

Bit twiddling

Symbol reading

When a symbol table is requested (through a call to bfd_canonicalize_symtab), a request gets through to coff_get_normalized_symtab. This reads the symbol table from the coff file and swaps all the structures inside into the internal form. It also fixes up all the pointers in the table (represented in the file by offsets from the first symbol in the table) into physical pointers to elements in the new internal table. This involves some work since the meanings of fields change depending upon context: a field that is a pointer to another structure in the symbol table at one moment may be the size in bytes of a structure at the next. Another pass is made over the table. All symbols which mark file names (C_FILE symbols) are modified so that the internal string points to the value in the auxent (the real filename) rather than the normal text associated with the symbol (".file").

At this time the symbol names are moved around. Coff stores all symbols less than nine characters long physically within the symbol table; longer strings are kept at the end of the file in the string table. This pass moves all strings into memory and replaces them with pointers to the strings.

The symbol table is massaged once again, this time to create the canonical table used by the BFD application. Each symbol is inspected in turn, and a decision made (using the sclass field) about the various flags to set in the asymbol. See [Symbols]. The generated canonical table shares strings with the hidden internal symbol table.

Any linenumbers are read from the coff file too, and attached to the symbols which own the functions the linenumbers belong to.

Symbol writing

When the symbols have come from a coff file then all the debugging information is preserved.

Symbol tables are provided for writing to the back end in a vector of pointers to pointers. This allows applications like the linker to accumulate and output large symbol tables without having to do too much byte copying.

This function runs through the provided symbol table and patches each symbol marked as a file place holder (C_FILE) to point to the next file place holder in the list. It also marks each offset field in the list with the offset from the first symbol of the current symbol.

Another function of this procedure is to turn the canonical value form of BFD into the form used by coff. Internally, BFD expects symbol values to be offsets from a section base; so a symbol physically at 0x120, but in a section starting at 0x100, would have the value 0x20. Coff expects symbols to contain their final value, so symbols have their values changed at this point to

ELF backends

Documentation of the internals of the support code still needs to be written. The code is changing quickly enough that we haven't bothered yet.

GNU Free Documentation License

GNU Free Documentation License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties-for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

    Copyright (c)  YEAR  YOUR NAME.
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.1
    or any later version published by the Free Software Foundation;
    with the Invariant Sections being LIST THEIR TITLES, with the
    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".

If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

Index

Menu