-\input texinfo
+\input texinfo.tex
@setfilename bfd.info
-@c $Id$
+@c Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1997, 2000
+@c Free Software Foundation, Inc.
+@c
+@tex
+% NOTE LOCAL KLUGE TO AVOID TOO MUCH WHITESPACE
+\global\long\def\example{%
+\begingroup
+\let\aboveenvbreak=\par
+\let\afterenvbreak=\par
+\parskip=0pt
+\lisp}
+\global\long\def\Eexample{%
+\Elisp
+\endgroup
+\vskip -\parskip% to cancel out effect of following \par
+}
+@end tex
@synindex fn cp
@ifinfo
@format
START-INFO-DIR-ENTRY
-* Bfd: (bfd). The Binary File Descriptor library.
+* Bfd: (bfd). The Binary File Descriptor library.
END-INFO-DIR-ENTRY
@end format
@end ifinfo
@ifinfo
This file documents the BFD library.
-Copyright (C) 1991 Free Software Foundation, Inc.
+Copyright (C) 1991, 2000, 2001 Free Software Foundation, Inc.
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
+ 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".
@ignore
Permission is granted to process this file through Tex and print the
(this paragraph not being relevant to the printed manual).
@end ignore
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, subject to the terms
-of the GNU General Public License, which includes the provision that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
@end ifinfo
@iftex
@c@finalout
@title{libbfd}
@subtitle{The Binary File Descriptor Library}
@sp 1
-@subtitle First Edition---BFD version < 2.0
-@subtitle April 1991
+@subtitle First Edition---BFD version < 3.0 % Since no product is stable berfore version 3.0 :-)
+@subtitle Original Document Created: April 1991
@author {Steve Chamberlain}
@author {Cygnus Support}
@page
\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
\xdef\manvers{\$Revision$} % For use in headers, footers too
{\parskip=0pt
-\hfill Cygnus Support\par
-\hfill steve\@cygnus.com\par
+\hfill Free Software Foundation\par
+\hfill sac\@www.gnu.org\par
\hfill {\it BFD}, \manvers\par
\hfill \TeX{}info \texinfoversion\par
}
@end tex
@vskip 0pt plus 1filll
-Copyright @copyright{} 1991 Free Software Foundation, Inc.
-
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
+Copyright @copyright{} 1991, 2001 Free Software Foundation, Inc.
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, subject to the terms
-of the GNU General Public License, which includes the provision that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
+ 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".
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
@end titlepage
@end iftex
@menu
* Overview:: Overview of BFD
* BFD front end:: BFD front end
-* BFD back end:: BFD back end
+* BFD back ends:: BFD back ends
+* GNU Free Documentation License:: GNU Free Documentation License
* Index:: Index
@end menu
@chapter Introduction
@cindex BFD
@cindex what is it?
-Simply put, BFD is a package which allows applications to use the
+BFD is a package which allows applications to use the
same routines to operate on object files whatever the object file
-format. A different object file format can be supported simply by
+format. A new object file format can be supported simply by
creating a new BFD back end and adding it to the library.
-BFD is split into two parts; the front end and the many back ends.
+BFD is split into two parts: the front end, and the back ends (one for
+each object file format).
@itemize @bullet
@item 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.
+memory and various canonical data structures. The front end also
+decides which back end to use and when to call back end routines.
@item 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
@menu
* History:: History
* How It Works:: How It Works
-* What BFD Version 1 Can Do:: What BFD Version 1 Can Do
+* What BFD Version 2 Can Do:: What BFD Version 2 Can Do
@end menu
@node History, How It Works, Overview, Overview
One spur behind BFD was the desire, on the part of the GNU 960 team at
Intel Oregon, for interoperability of applications on their COFF and
b.out file formats. Cygnus was providing GNU support for the team, and
-Cygnus was contracted to provide the required functionality.
+was contracted to provide the required functionality.
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
different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k
coff.
-BFD was first implemented by Steve Chamberlain (steve@@cygnus.com),
-John Gilmore (gnu@@cygnus.com), K. Richard Pixley (rich@@cygnus.com) and
-David Wallace (gumby@@cygnus.com) at Cygnus Support in Palo Alto,
-California.
+BFD was first implemented by members of Cygnus Support; Steve
+Chamberlain (@code{sac@@cygnus.com}), John Gilmore
+(@code{gnu@@cygnus.com}), K. Richard Pixley (@code{rich@@cygnus.com})
+and David Henkel-Wallace (@code{gumby@@cygnus.com}).
-@node How It Works, What BFD Version 1 Can Do, History, Overview
-@section How It Works
-To use the library, include @code{bfd.h} and link with @code{libbfd.a}.
+
+@node How It Works, What BFD Version 2 Can Do, History, Overview
+@section How To Use BFD
+
+To use the library, include @file{bfd.h} and link with @file{libbfd.a}.
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
+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 @code{bfd}, described in
-@code{include/bfd.h}. Our convention is to call this pointer a BFD, and
+@file{bfd.h}. Our convention is to call this pointer a BFD, and
instances of it within code @code{abfd}. All operations on
the target object file are applied as methods to the BFD. The mapping is
defined within @code{bfd.h} in a set of macros, all beginning
-@samp{bfd}_.
+with @samp{bfd_} to reduce namespace pollution.
-For example, this sequence would do what you would probably expect:
+For example, this sequence does what you would probably expect:
return the number of sections in an object file attached to a BFD
@code{abfd}.
@c @end cartouche
@end lisp
-The abstraction used within BFD is that an object file has a header,
-a number of sections containing raw data, a set of relocations, and some
-symbol information. 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.
-
-@node What BFD Version 1 Can Do, , How It Works, Overview
-@section What BFD Version 1 Can Do
-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 the memory pointer to the relevant BFD
-back end routine 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 which takes the newly
-created symbol table and converts it into the chosen output format.
+The abstraction used within BFD is that an object file has:
-@menu
-* BFD information loss:: Information Loss
-* Mechanism:: Mechanism
-@end menu
+@itemize @bullet
+@item
+a header,
+@item
+a number of sections containing raw data (@pxref{Sections}),
+@item
+a set of relocations (@pxref{Relocations}), and
+@item
+some symbol information (@pxref{Symbols}).
+@end itemize
+@noindent
+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.
-@node BFD information loss, Mechanism, What BFD Version 1 Can Do, What BFD Version 1 Can Do
-@subsection Information Loss
-@emph{Some information is lost due to the nature of the file format.} The output targets
-supported by BFD do not provide identical facilities, and
-information which may be described in one form has nowhere to go in
-another format. One example of this is alignment information in
-@code{b.out}. There is nowhere in an @code{a.out} format file to store
-alignment information on the contained data, so when a file is linked
-from @code{b.out} and an @code{a.out} image is produced, alignment
-information will not propagate to the output file. (The linker will
-still use the alignment information internally, so the link is performed
-correctly).
-
-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 (eg
-@code{a.out}) or has sections without names (eg 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.
-
-@emph{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, this mechanism
-is very useful. There is no information lost for this reason when
-linking or copying big endian COFF to little endian COFF, or @code{a.out} to
-@code{b.out}. When a mixture of formats is linked, the information is
-only lost from the files whose format differs from the destination.
-
-@node Mechanism, , BFD information loss, What BFD Version 1 Can Do
-@subsection Mechanism
-The greatest potential for loss of information is when there is least
-overlap between the information provided by the source format, that
-stored by the canonical format, and the information needed by the
-destination format. A brief description of the canonical form may help
-you appreciate what kinds of data you can count on preserving across
-conversions.
-@cindex BFD canonical format
-@cindex internal object-file format
-
-@table @emph
-@item files
-Information on target machine architecture, particular implementation
-and format type are stored on a per-file basis. Other information
-includes a demand pageable bit and a write protected bit. Note that
-information like Unix magic numbers is not stored here---only the magic
-numbers' meaning, so a @code{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 linked with one another.
-@c FIXME: generalize above from "link"?
-
-@item sections
-Each section in the input file contains the name of the section, the
-original address in the object file, various flags, size and alignment
-information and pointers into other BFD data structures.
-
-@item symbols
-Each symbol contains a pointer to 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, the back end relocates all
-symbols to make them relative to the base of the section where they were
-defined. This ensures that each symbol points to its containing
-section. Each symbol also has a varying amount of hidden data to contain
-private data for the BFD back end. Since the symbol points to the
-original file, the private data format for that symbol is accessible.
-@code{gld} can operate on a collection of symbols of wildly different
-formats without problems.
-
-Normal global and simple local symbols are maintained on output, so an
-output file (no matter its format) will retain symbols pointing to
-functions and to global, static, and common variables. Some symbol
-information is not worth retaining; in @code{a.out} 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.
-
-@item 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 effectively by message passing through the relocation type
-descriptor and symbol pointer. It allows relocations to be performed
-on output data using a relocation method 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 COFF file, even though 68k COFF
-has no such relocation type.
-
-@item 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 divination of 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).
-@end table
-
-@c FIXME: what is this line about? Do we want introductory remarks
-@c FIXME... on back ends? commented out for now.
-@c What is a backend
-
-
-@node BFD front end, BFD back end, Overview, Top
+@node What BFD Version 2 Can Do, , How It Works, Overview
+@section What BFD Version 2 Can Do
+@include bfdsumm.texi
+
+@node BFD front end, BFD back ends, Overview, Top
@chapter BFD front end
-@include bfd.texi
+@include bfdt.texi
@menu
* Memory Usage::
* Targets::
* Architectures::
* Opening and Closing::
-* Constructors::
* Internal::
* File Caching::
+* Linker Functions::
+* Hash Tables::
@end menu
@node Memory Usage, Initialization, BFD front end, BFD front end
-@section Memory Usage
-BFD keeps all its internal structures in obstacks. There is one obstack
+@section Memory usage
+BFD keeps all of its internal structures in obstacks. There is one obstack
per open BFD file, into which the current state is stored. When a BFD is
closed, the obstack is deleted, and so everything which has been
-allocated by libbfd for the closing file will be thrown away.
+allocated by BFD for the closing file is thrown away.
-BFD will not free anything created by an application, but pointers into
-@code{bfd} structures will be invalidated on a @code{bfd_close}; for example,
+BFD does not free anything created by an application, but pointers into
+@code{bfd} structures become invalid on a @code{bfd_close}; for example,
after a @code{bfd_close} the vector passed to
-@code{bfd_canonicalize_symtab} will still be around, since it has been
-allocated by the application, but the data that it pointed to will be
+@code{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 not to close a BFD until all operations dependent
+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
-(@code{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.
+the file has been copied. To help with the management of memory, there
+is a function (@code{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.
@node Initialization, Sections, Memory Usage, BFD front end
@include init.texi
@node Architectures, Opening and Closing, Targets, BFD front end
@include archures.texi
-@node Opening and Closing, Constructors, Architectures, BFD front end
+@node Opening and Closing, Internal, Architectures, BFD front end
@include opncls.texi
-@node Constructors, Internal, Opening and Closing, BFD front end
-@include ctor.texi
-
-@node Internal, File Caching, Constructors, BFD front end
+@node Internal, File Caching, Opening and Closing, BFD front end
@include libbfd.texi
-@node File Caching, , Internal, BFD front end
+@node File Caching, Linker Functions, Internal, BFD front end
@include cache.texi
-@node BFD back end, Index, BFD front end, Top
-@chapter BFD back end
+@node Linker Functions, Hash Tables, File Caching, BFD front end
+@include linker.texi
+
+@node Hash Tables, , Linker Functions, BFD front end
+@include hash.texi
+
+@node BFD back ends, GNU Free Documentation License, BFD front end, Top
+@chapter BFD back ends
@menu
-* What to put where::
+* What to Put Where::
* aout :: a.out backends
* coff :: coff backends
+* elf :: elf backends
+* mmo :: mmo backend
@ignore
* oasys :: oasys backends
* ieee :: ieee backend
* srecord :: s-record backend
@end ignore
@end menu
-@node What to Put Where, aout, BFD back end, BFD back end
+@node What to Put Where, aout, BFD back ends, BFD back ends
All of BFD lives in one directory.
-@node aout, coff, What to Put Where, BFD back end
+@node aout, coff, What to Put Where, BFD back ends
@include aoutx.texi
-@node coff, , aout, BFD back end
+@node coff, elf, aout, BFD back ends
@include coffcode.texi
-@node Index, , BFD back end, Top
+@node elf, mmo, coff, BFD back ends
+@include elf.texi
+@c Leave this out until the file has some actual contents...
+@c @include elfcode.texi
+
+@node mmo, , elf, BFD back ends
+@include mmo.texi
+
+@node GNU Free Documentation License, Index, BFD back ends, Top
+@chapter GNU Free Documentation License
+@cindex 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:
+
+@smallexample
+ 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".
+@end smallexample
+
+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.
+
+@node Index, , GNU Free Documentation License , Top
@unnumbered Index
@printindex cp
\centerline{{\sl\fontname\tensl\/}}
\centerline{are used for emphasis.}\vfill}
\page\colophon
-% Blame: pesch@cygnus.com, 28mar91.
+% Blame: doc@cygnus.com, 28mar91.
@end tex
@contents
@bye
-
-
projects / deliverable / binutils-gdb.git / blobdiff