recording file death

24 files changed, 0 insertions, 1790 deletions

diff --git a/bfd/doc/Makefile b/bfd/doc/Makefile
deleted file mode 100755
index 2ac5d43..0000000
--- a/bfd/doc/Makefile
+++ /dev/null
@@ -1,82 +0,0 @@
-.SUFFIXES: .texi .o .c .h .p .ip
-VPATH=..
-.c.texi:
-	./scanit $< $@
-
-.h.texi:
-	./scanit $< $@
-
-.c.p:
-	./scanph $< $@
-
-.h.p:
-	./scanph $< $@
-
-.c.ip:
-	./scanph -i $< $@
-
-# main GDB source directory
-srcdir = ..
-
-TEXIDIR=${srcdir}/../texinfo/fsf
-
-DOCFILES = aoutx.texi  archive.texi archures.texi \
-	bfd.texi  cache.texi coffcode.texi \
-	core.texi  format.texi  libbfd.texi  \
-	opncls.texi  reloc.texi  section.texi  \
-	syms.texi  targets.texi init.texi ctor.texi
-	
-
-PROTOS = archive.p archures.p bfd.p \
-	coffcode.p core.p format.p \
-	libbfd.p opncls.p reloc.p \
-	section.p syms.p targets.p  \
-	format.p coffcode.p core.p machines.p init.p
-
-IPROTOS = cache.ip libbfd.ip reloc.ip init.ip archures.ip ctor.ip 
-
-# SRCDOC, SRCPROT, SRCIPROT only used to sidestep Sun Make bug in interaction 
-# between VPATH and suffix rules.  If you use GNU Make, perhaps other Makes,
-# you don't need these three:
-SRCDOC = aoutx.h  archive.c archures.c \
-	bfd.c  cache.c coffcode.h \
-	core.c  format.c  libbfd.c  \
-	opncls.c  reloc.c  section.c  \
-	syms.c  targets.c init.c
-
-SRCPROT = archive.c archures.c bfd.c \
-	coffcode.h core.c format.c \
-	libbfd.c opncls.c reloc.c \
-	section.c syms.c targets.c init.c
-
-SRCIPROT = cache.c libbfd.c reloc.c cpu-h8300.c  cpu-i960.c archures.c init.c ctor.c
-
-
-docs: protos bfd.info bfd.dvi bfd.ps
-
-protos: $(PROTOS) $(IPROTOS)
-	sed -f intobfd bfd-in.h  > bfd.h
-	sed -f tolibbfd libbfd-in.h  > libbfd.h
-	sed -f tolibcoff libcoff-in.h  > libcoff.h
-
-# Following three rules only for the benefit of Sun Make; see comment above
-$(DOCFILES) : $(SRCDOC)
-$(PROTOS) : $(SRCPROT)
-$(IPROTOS) : $(SRCIPROT)
-
-clean:
-	rm -f $(PROTOS) *.p *.ip *.h bfd.?? $(DOCFILES) bfd.dvi bfd.ps *~* *# bfd.??? 
-
-bfd.info: $(DOCFILES) bfd.texinfo
-	makeinfo bfd.texinfo
-
-bfd.dvi: $(DOCFILES) bfd.texinfo
-	TEXINPUTS=${TEXIDIR}:.:$$TEXINPUTS tex bfd.texinfo
-	texindex bfd.??
-	TEXINPUTS=${TEXIDIR}:.:$$TEXINPUTS tex bfd.texinfo
-
-bfd.ps: bfd.dvi
-	dvips bfd -o
-	
-quickdoc: $(DOCFILES) bfd.texinfo
-	TEXINPUTS=${TEXIDIR}:.:$$TEXINPUTS tex bfd.texinfo
diff --git a/bfd/doc/awkscan b/bfd/doc/awkscan
deleted file mode 100755
index 69b0cea..0000000
--- a/bfd/doc/awkscan
+++ /dev/null
@@ -1,12 +0,0 @@
-# NOTE: BEGIN pattern gives errors if other than 1st line; 
-# END ditto if other than last.
-BEGIN { print "@c ------------------------------START TEXT FROM " FILENAME }
-#
-# Keep /*doc* blocks (terminated by either */ or *-*/)
-/^\/\*doc\*/,/^\*\/|^\*-\*\//
-#
-# Also keep two kinds of /*proto blocks
-/^\/\*proto\*/,/^\*\/|^\*-\*\//
-/^\/\*proto-internal\*/,/^\*\/|^\*-\*\//
-#
-END { print "@c ------------------------------END TEXT FROM " FILENAME }
diff --git a/bfd/doc/awkscan-ip b/bfd/doc/awkscan-ip
deleted file mode 100755
index 73bd61f..0000000
--- a/bfd/doc/awkscan-ip
+++ /dev/null
@@ -1,8 +0,0 @@
-# Awk filter, 1st filter for BFD internal prototype file extraction
-#
-# keep /*proto-internal blocks
-/^\/\*proto-internal\*/,/^\*\/|^\*-\*\//
-#
-# Apparent bug in sed can discard last line in some situations; therefore
-# make last line harmless.
-END { print "\n" }
diff --git a/bfd/doc/awkscan-p b/bfd/doc/awkscan-p
deleted file mode 100755
index c7fe79f..0000000
--- a/bfd/doc/awkscan-p
+++ /dev/null
@@ -1,8 +0,0 @@
-# Awk filter, 1st filter for BFD prototype file extraction
-#
-# keep /*proto blocks
-/^\/\*proto\*/,/^\*\/|^\*-\*\//
-#
-# Apparent bug in sed can discard last line in some situations; therefore
-# make last line harmless.
-END { print "\n" }
diff --git a/bfd/doc/bfd.info b/bfd/doc/bfd.info
deleted file mode 100644
index 529d69d..0000000
--- a/bfd/doc/bfd.info
+++ /dev/null
@@ -1,67 +0,0 @@
-Info file bfd.info, produced by Makeinfo, -*- Text -*- from input file
-bfd.texinfo.
-
-   This file documents the BFD library.
-
-   Copyright (C) 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.
-
-   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.
-
-Indirect:
-bfd.info-1: 821
-bfd.info-2: 44533
-bfd.info-3: 89652
-
-Tag Table:
-(Indirect)
-Node: Top823
-Node: Overview1086
-Node: History1985
-Node: How It Works2937
-Node: What BFD Version 1 Can Do4363
-Node: BFD information loss5388
-Node: Mechanism8002
-Node: BFD front end12332
-Node: Memory Usage17576
-Node: Initialization18818
-Node: Sections19432
-Node: Section Input19910
-Node: Section Output21190
-Node: typedef asection22559
-Node: section prototypes27347
-Node: Symbols30865
-Node: Reading Symbols32454
-Node: Writing Symbols33410
-Node: typedef asymbol34939
-Node: symbol handling functions38386
-Node: Archives40232
-Node: Formats41678
-Node: Relocations43795
-Node: typedef arelent44535
-Node: howto manager56584
-Node: Core Files57569
-Node: Targets58466
-Node: bfd_target60218
-Node: Architectures68923
-Node: Opening and Closing76770
-Node: Internal78654
-Node: File Caching81129
-Node: BFD back end83617
-Node: What to Put Where83810
-Node: aout83946
-Node: coff89654
-Node: Index100603
-
-End Tag Table
diff --git a/bfd/doc/bfdinfo b/bfd/doc/bfdinfo
deleted file mode 100755
index 5bb06ff..0000000
--- a/bfd/doc/bfdinfo
+++ /dev/null
@@ -1,1281 +0,0 @@
-Info file bfdinfo, produced by Makeinfo, -*- Text -*- from input file
-bfd.texinfo.
-
-   This file documents the BFD library.
-
-   Copyright (C) 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.
-
-   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.
-
-
-File: bfdinfo,  Node: Top,  Next: Overview,  Prev: (dir),  Up: (dir)
-
-   This file documents the binary file descriptor library libbfd.
-
-* Menu:
-
-* Overview::			Overview of BFD
-* History::			History of BFD
-* Backends::			Backends
-* Porting::			Porting
-* Future::			Future
-* Index::			Index
-
-BFD body:
-* Memory usage::
-* Sections::
-* Symbols::
-* Archives::
-* Formats::
-* Relocations::
-* Core Files::
-* Targets::
-* Architecturs::
-* Opening and Closing::
-* Internal::
-* File Caching::
-
-BFD backends:
-* a.out backends::
-* coff backends::
-
-
-File: bfdinfo,  Node: Overview,  Next: History,  Prev: Top,  Up: Top
-
-Introduction
-************
-
-   Simply put, 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
-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.
-
-   * memory, and various canonical data structures. The front end also
-     decides which back end to use, and when to call back end routines.
-
-   * 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.
-
-
-File: bfdinfo,  Node: History,  Next: How It Works,  Prev: Overview,  Up: Top
-
-History
-=======
-
-   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.
-
-   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 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.
-
-
-File: bfdinfo,  Node: How It Works,  Next: History,  Prev: Porting,  Up: Top
-
-How It Works
-============
-
-   To use the library, include `bfd.h' and link with `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 points to a structure called `bfd', described in
-`include/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 `bfd'_.
-
-   For example, this sequence would do 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);
-     }
-
-   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.
-
-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.
-
-
-File: bfdinfo,  Node: BFD information loss,  Next: Mechanism,  Prev: BFD outline,  Up: BFD
-
-Information Loss
-----------------
-
-   *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 `b.out'. There is nowhere in an `a.out' format file to
-store alignment information on the contained data, so when a file is
-linked from `b.out' and an `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 `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.
-
-   *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 `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.
-
-
-File: bfdinfo,  Node: Mechanism,  Prev: BFD information loss,  Up: BFD
-
-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.
-
-*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 `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.
-
-*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.
-
-*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.  `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
-     `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 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.
-
-*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).
-
-
-File: bfdinfo,  Node: BFD front end,  Next: BFD back end,  Prev: Mechanism,  Up: Top
-
-BFD front end
-*************
-
-typedef bfd
-===========
-
-   Pointers to bfd structs are the cornerstone of any application using
-`libbfd'. References though the BFD and to data in the BFD give the
-entire BFD functionality.
-
-   Here is the BFD struct itself.  This contains the major data about
-the file, and contains 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.
-
-       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.
-
-       char *iostream;
-
-   Is the file being cached *Note File Caching::.
-
-       boolean cacheable;
-
-   Marks whether there was a default target specified when the BFD was
-opened. This is used to select what matching algorithm to use to chose
-the back end.
-
-       boolean target_defaulted;
-
-   The caching routines use these to maintain a least-recently-used
-list of BFDs (*note File Caching::.).
-
-       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:
-
-       boolean opened_once;
-
-       boolean mtime_set;
-
-   File modified time
-
-       long mtime;
-
-   Reserved for an unimplemented file locking extension.
-
-     int ifd;
-
-   The format which belongs to the BFD.
-
-       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 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
-
-       struct symbol_cache_entry  **outsymbols;
-
-   Architecture of object machine, eg m68k
-
-       enum bfd_architecture obj_arch;
-
-   Particular machine within arch, e.g. 68010
-
-       unsigned long obj_machine;
-
-   Stuff only useful for archives:
-
-       PTR arelt_data;              
-       struct _bfd *my_archive;     
-       struct _bfd *next;           
-       struct _bfd *archive_head;   
-       boolean has_armap;
-
-   Used by the back end to hold private data.
-
-       PTR tdata;
-
-   Used by the application to hold private data
-
-       PTR usrdata;
-
-   Where all the allocated stuff under this BFD goes (*note Memory
-Usage::.).
-
-       struct obstack memory;
-     };
-
-`bfd_set_start_address'
-.......................
-
-   Marks the entry point of an output BFD. Returns `true' on success,
-`false' otherwise.
-
-     boolean bfd_set_start_address(bfd *, bfd_vma);
-
-`bfd_get_mtime'
-...............
-
-   Return cached file modification time (e.g. as read from archive
-header for archive members, or from file system if we have been called
-before); else determine modify time, cache it, and return it.
-
-     long bfd_get_mtime(bfd *);
-
-`stuff'
-.......
-
-
-
-     #define bfd_sizeof_headers(abfd, reloc) \
-          BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, reloc))
-     
-     #define bfd_find_nearest_line(abfd, section, symbols, offset, filename_ptr, func, line_ptr) \
-          BFD_SEND (abfd, _bfd_find_nearest_line,  (abfd, section, symbols, offset, filename_ptr, func, line_ptr))
-     
-     #define bfd_debug_info_start(abfd) \
-             BFD_SEND (abfd, _bfd_debug_info_start, (abfd))
-     
-     #define bfd_debug_info_end(abfd) \
-             BFD_SEND (abfd, _bfd_debug_info_end, (abfd))
-     
-     #define bfd_debug_info_accumulate(abfd, section) \
-             BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section))
-     
-     #define bfd_stat_arch_elt(abfd, stat) \
-             BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat))
-     
-     #define bfd_coff_swap_aux_in(a,e,t,c,i) \
-             BFD_SEND (a, _bfd_coff_swap_aux_in, (a,e,t,c,i))
-     
-     #define bfd_coff_swap_sym_in(a,e,i) \
-             BFD_SEND (a, _bfd_coff_swap_sym_in, (a,e,i))
-     
-     #define bfd_coff_swap_lineno_in(a,e,i) \
-             BFD_SEND ( a, _bfd_coff_swap_lineno_in, (a,e,i))
-
-   lisp
-
-
-File: bfdinfo,  Node: Memory Usage,  Next: Sections,  Prev: bfd,  Up: Top
-
-Memory Usage
-============
-
-   BFD keeps all 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.
-
-   BFD will not free anything created by an application, but pointers
-into `bfd' structures will be invalidated on a `bfd_close'; for
-example, after a `bfd_close' the vector passed to
-`bfd_canonicalize_symtab' will still be around, since it has been
-allocated by the application, but the data that it pointed to will be
-lost.
-
-   The general rule is not to 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.
-
-
-File: bfdinfo,  Node: Sections,  Next: Symbols,  Prev: Memory Usage,  Up: Top
-
-Sections
-========
-
-   Sections are supported in BFD in `section.c'.
-
-   The raw data contained within a BFD is maintained through the
-section abstraction.  A single BFD may have any number of sections,
-and keeps hold of them by pointing to the first, each one points to
-the next in the list.
-
-* Menu:
-
-* Section Input::
-* Section Output::
-* typedef asection::
-* section prototypes::
-
-
-File: bfdinfo,  Node: Section Input,  Next: Section Output,  Up: Sections
-
-Section Input
--------------
-
-   When a BFD is opened for reading, the section structures are created
-and attached to the BFD.
-
-   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'.
-
-   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 a supernumary section `COMMON' for each input file's BFD to
-hold information about common storage.
-
-   The raw data is not necessarily read in at the same time as 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.
-
-
-File: bfdinfo,  Node: Section Output,  Next: typedef asection,  Prev: Section Input,  Up: Sections
-
-Section Output
---------------
-
-   To write a new object style BFD, the various sections to be written
-have to be created. They are attached to the BFD in the same way as
-input sections, data is written to the sections using
-`bfd_set_section_contents'.
-
-   The linker uses the fields `output_section' and `output_offset' to
-create an output file.
-
-   The data to be written comes from input sections attached 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.
-
-   Eg to create a section "O", starting at 0x100, 0x123 long,
-containing two subsections, "A" at offset 0x0 (ie at vma 0x100) and
-"B" at offset 0x20 (ie at vma 0x120) the 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  --------|
-
-   lisp
-
-
-File: bfdinfo,  Node: typedef asection,  Next: section prototypes,  Prev: Section Output,  Up: Sections
-
-typedef asection
-----------------
-
-   The shape of a section struct:
-
-     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;
-
-   The next section in the list belonging to the BFD, or NULL.
-
-         struct sec *next;
-
-   The field flags contains attributes of the section. Some of these
-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 loaded.  This
-would 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
-would be clear for a .bss section
-
-     #define SEC_LOAD       0x002
-
-   The section contains data still to be relocated, so there will be
-some relocation information too.
-
-     #define SEC_RELOC      0x004
-
-   Obsolete
-
-     #define SEC_BALIGN     0x008
-
-   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 (eg
-`__CTOR_LIST__'), attaches the symbol to it and builds a relocation.
-To build the lists of constructors, all the linker has to to is
-catenate all the sections called `__CTOR_LIST__' and relocte the data
-contained within - exactly the operations it would peform on standard
-data.
-
-     #define SEC_CONSTRUCTOR 0x100
-
-   The section is a constuctor, and should be placed at the end of the
-..
-
-     #define SEC_CONSTRUCTOR_TEXT 0x1100
-
-     #define SEC_CONSTRUCTOR_DATA 0x2100
-
-     #define SEC_CONSTRUCTOR_BSS  0x3100
-
-   The section has contents - a bss 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 not to output sections containing this
-flag even if they have information which would normally be written.
-
-     #define SEC_NEVER_LOAD 0x400
-
-   The base address of the section in the address space of the target.
-
-        bfd_vma vma;
-
-   The size of the section in bytes of the loaded section. This
-contains a value even if the section has no contents (eg, the size of
-`.bss').
-
-        bfd_size_type size;
-
-   If this section is going to be output, then this value is the
-offset into the output section of the first byte in the input section.
-Eg, if this was going to start at the 100th byte in the output
-section, this value would be 100.
-
-        bfd_vma output_offset;
-
-   The output section through which to map on output.
-
-        struct sec *output_section;
-
-   The alignment requirement of the section, as an exponent - eg 3
-aligns to 2^3 (or 8)
-
-        unsigned int alignment_power;
-
-   If an input section, a pointer to a vector of relocation records for
-the data in this section.
-
-        struct reloc_cache_entry *relocation;
-
-   If an output section, a pointer to a vector of pointers to
-relocation records for the data in this section.
-
-        struct reloc_cache_entry **orelocation;
-
-   The number of relocation records in one of the above
-
-        unsigned reloc_count;
-
-   Which section is it 0..nth
-
-        int index;
-
-   Information below is back end specific - and not always used or
-updated
-
-   File position of section data
-
-        file_ptr filepos;
-
-   File position of relocation info
-
-        file_ptr rel_filepos;
-
-   File position of line data
-
-        file_ptr line_filepos;
-
-   Pointer to data for applications
-
-        PTR userdata;
-
-        struct lang_output_section *otheruserdata;
-
-   Attached line number information
-
-        alent *lineno;
-
-   Number of line number records
-
-        unsigned int lineno_count;
-
-   When a section is being output, this value changes as more
-linenumbers are written out
-
-        file_ptr moving_line_filepos;
-
-   what the section number is in the target world
-
-        unsigned int target_index;
-
-        PTR used_by_bfd;
-
-   If this is a constructor section then here is a list of the
-relocations created to relocate items within it.
-
-        struct relent_chain *constructor_chain;
-
-   The BFD which owns the section.
-
-        bfd *owner;
-
-     } asection ;
-
-
-File: bfdinfo,  Node: section prototypes,  Next: Section,  Prev: typedef section,  Up: Sections
-
-section prototypes
-------------------
-
-`bfd_get_section_by_name'
-.........................
-
-   Runs through the provided ABFD and returns the `asection' who's
-name matches that provided, otherwise NULL. *Note Sections::, for more
-information.
-
-     asection * bfd_get_section_by_name(bfd *abfd, CONST char *name);
-
-`bfd_make_section'
-..................
-
-   This function creates a new empty section called NAME and attaches
-it to the end of the chain of sections for the BFD supplied. An
-attempt to create a section with a name which is already in use,
-returns the old section by that name instead.
-
-   Possible errors are:
-
-`invalid_operation'
-     If output has already started for this BFD.
-
-`no_memory'
-     If obstack alloc fails.
-
-     asection * bfd_make_section(bfd *, CONST char *name);
-
-`bfd_set_section_flags'
-.......................
-
-   Attempts to set the attributes of the section named in the BFD
-supplied to the value. Returns true on success, false on error. 
-Possible error returns are:
-
-`invalid operation'
-     The section cannot have one or more of the attributes requested.
-     For example, a .bss section in `a.out' may not have the
-     `SEC_HAS_CONTENTS' field set.
-
-     boolean bfd_set_section_flags(bfd *, asection *, flagword);
-
-`bfd_map_over_sections'
-.......................
-
-   Calls the provided function FUNC for each section attached to the
-BFD ABFD, passing OBJ as an argument. The function will be called as
-if by
-
-       func(abfd, the_section, obj);
-
-     void bfd_map_over_sections(bfd *abfd, void (*func)(), PTR obj);
-
-   This is the prefered method for iterating over sections, an
-alternative would be to use a loop:
-
-        section *p;
-        for (p = abfd->sections; p != NULL; p = p->next)
-           func(abfd, p, ...)
-
-`bfd_set_section_size'
-......................
-
-   Sets SECTION to the size VAL. If the operation is ok, then `true'
-is returned, else `false'.
-
-   Possible error returns:
-
-`invalid_operation'
-     Writing has started to the BFD, so setting the size is invalid
-
-     boolean bfd_set_section_size(bfd *, asection *, bfd_size_type val);
-
-`bfd_set_section_contents'
-..........................
-
-   Sets the contents of the section SECTION in BFD ABFD to the data
-starting in memory at DATA. The data is written to the output section
-starting at offset OFFSET for COUNT bytes.
-
-   Normally `true' is returned, else `false'. Possible error returns
-are:
-
-`no_contents'
-     The output section does not have the `SEC_HAS_CONTENTS'
-     attribute, so nothing can be written to it.
-
-`and some more too'
-   This routine is front end to the back end function
-`_bfd_set_section_contents'.
-
-     boolean bfd_set_section_contents(bfd *abfd,        
-              asection *section,
-              PTR data,
-              file_ptr offset,
-              bfd_size_type count);
-
-`bfd_get_section_contents'
-..........................
-
-   This function reads data from SECTION in BFD ABFD into memory
-starting at LOCATION. The data is read at an offset of OFFSET from the
-start of the input section, and is read for COUNT bytes.
-
-   If the contents of a constuctor with the `SEC_CONSTUCTOR' flag set
-are requested, then the LOCATION is filled with zeroes.
-
-   If no errors occur, `true' is returned, else `false'.  Possible
-errors are:
-
-`unknown yet'
-     boolean bfd_get_section_contents(bfd *abfd, asection *section, PTR location,
-              file_ptr offset, bfd_size_type count);
-
-
-File: bfdinfo,  Node: Symbols,  Next: Archives,  Prev: Sections,  Up: To
-
-Symbols
-=======
-
-   BFD trys to maintain as much symbol information as it can when it
-moves information from file to file. BFD passes information to
-applications though the `asymbol' structure. When the application
-requests the symbol table, BFD reads the table in the native form and
-translates parts of it into the internal format. To maintain more than
-the infomation passed to applications some targets keep some
-information 'behind the sceans', in a structure only the particular
-back end knows about. For example, the coff back end keeps the
-original symbol table structure as well as the canonical structure
-when a BFD is read in. On output, the coff back end can reconstruct
-the output symbol table so that no information is lost, even
-information unique to coff which BFD doesn't know or understand. If a
-coff symbol table was read, but was written through an a.out back end,
-all the coff specific information would be lost. (.. until BFD 2 :).
-
-   The symbol table of a BFD is not necessarily read in until a
-canonicalize request is made. Then the BFD back end fills in a table
-provided by the application with pointers to the canonical information.
-
-   To output symbols, the application provides BFD with a table of
-pointers to pointers to `asymbol's. This allows applications like the
-linker to output a symbol as read, since the 'behind the sceens'
-information will be still available.
-
-* Menu:
-
-* Reading Symbols::
-* Writing Symbols::
-* typedef asymbol::
-* symbol handling functions::
-
-
-File: bfdinfo,  Node: Reading Symbols,  Next: Writing Symbols,  Prev: Symbols,  Up: Symbols
-
-Reading Symbols
----------------
-
-   There are two stages to reading a symbol table from a BFD;
-allocating storage, and the actual reading process. This is an excerpt
-from an appliction which reads the symbol table:
-
-
-       unsigned int storage_needed;
-       asymbol **symbol_table;
-       unsigned int number_of_symbols;
-       unsigned int i;
-     
-       storage_needed = get_symtab_upper_bound (abfd);
-     
-       if (storage_needed == 0) {
-          return ;
-       }
-       symbol_table = (asymbol **) malloc (storage_needed);
-         ...
-       number_of_symbols = 
-          bfd_canonicalize_symtab (abfd, symbol_table); 
-     
-       for (i = 0; i < number_of_symbols; i++) {
-          process_symbol (symbol_table[i]);
-       }
-
-   lisp
-
-   All storage for the symbols themselves is in an obstack connected to
-the BFD, and is freed when the BFD is closed.
-
-
-File: bfdinfo,  Node: Writing Symbols,  Next: typedef asymbol,  Prev: Reading Symbols,  Up: Symbols
-
-Writing Symbols
----------------
-
-   Writing of a symbol table is automatic when a BFD open for writing
-is closed. The application attaches a vector of pointers to pointers
-to symbols to the BFD being written, and fills in the symbol count.
-The close and cleanup code reads through the table provided and
-performs all the necessary operations. The outputing code must always
-be provided with an 'owned' symbol; one which has come from another
-BFD, or one which has been created using `bfd_make_empty_symbol'.
-
-   An example showing the creation of a symbol table with only one
-element:
-
-
-     #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 = (asection *)0;
-       new->flags = BSF_ABSOLUTE | 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
-
-   lisp
-
-   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.
-
-
-File: bfdinfo,  Node: typedef asymbol,  Next: symbol handling functions,  Prev: Writing Symbols,  Up: Symbols
-
-typedef asymbol
----------------
-
-   An `asymbol' has the form:
-
-     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 (invisible to
-the application writer) information is carried with the symbol.
-
-       struct _bfd *the_bfd;
-
-   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.
-
-        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
-
-   Obsolete
-
-     #define BSF_IMPORT	0x04
-
-   The symbol has global scope, and is exported. The value is the
-offset into the section of the data.
-
-     #define BSF_EXPORT	0x08
-
-   The symbol is undefined. `extern' in `C'. The value has no meaning.
-
-     #define BSF_UNDEFINED	0x10	
-
-   The symbol is common, initialized to zero; default in `C'. The
-value is the size of the object in bytes.
-
-     #define BSF_FORT_COMM	0x20	
-
-   A normal `C' symbol would be one of: `BSF_LOCAL', `BSF_FORT_COMM', 
-`BSF_UNDEFINED' or `BSF_EXPORT|BSD_GLOBAL'
-
-   The symbol is a debugging record. The value has an arbitary meaning.
-
-     #define BSF_DEBUGGING	0x40
-
-   The symbol has no section attached, any value is the actual value
-and is not a relative offset to a section.
-
-     #define BSF_ABSOLUTE	0x80
-
-   Used by the linker
-
-     #define BSF_KEEP        0x10000
-     #define BSF_KEEP_G      0x80000
-
-   Unused
-
-     #define BSF_WEAK        0x100000
-     #define BSF_CTOR        0x200000 
-     #define BSF_FAKE        0x400000
-
-   The symbol used to be a common symbol, but now it is allocated.
-
-     #define BSF_OLD_COMMON  0x800000
-
-   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    0x40000
-
-   Signal that the symbol is the label of constructor section.
-
-     #define BSF_CONSTRUCTOR   0x1000000
-
-   Signal that the symbol is a warning symbol. If the symbol is a
-warning symbol, then the value field (I know this is tacky) will point
-to the asymbol which when referenced will cause the warning.
-
-     #define BSF_WARNING       0x2000000
-
-   Signal that the symbol is indirect. The value of the symbol is a
-pointer to an undefined asymbol which contains the name to use instead.
-
-     #define BSF_INDIRECT     0x4000000
-
-       flagword flags;
-
-   A pointer to the section to which this symbol is relative, or 0 if
-the symbol is absolute or undefined. Note that it is not sufficient to
-set this location to 0 to mark a symbol as absolute - the flag
-`BSF_ABSOLUTE' must be set also.
-
-       struct sec *section;
-
-   Back end special data. This is being phased out in favour of making
-this a union.
-
-       PTR udata;	
-     } asymbol;
-
-
-File: bfdinfo,  Node: symbol handling functions,  Next: Symbols,  Prev: typedef asymbol,  Up: Symbols
-
-Symbol Handling Functions
--------------------------
-
-`get_symtab_upper_bound'
-........................
-
-   Returns the number of bytes required in a vector of pointers to
-`asymbols' for all the symbols in the supplied BFD, including a
-terminal NULL pointer. If there are no symbols in the BFD, then 0 is
-returned.
-
-
-     #define get_symtab_upper_bound(abfd) \
-          BFD_SEND (abfd, _get_symtab_upper_bound, (abfd))
-
-   lisp
-
-`bfd_canonicalize_symtab'
-.........................
-
-   Supplied a BFD and a pointer to an uninitialized vector of pointers. 
-This reads in the symbols from the BFD, and fills in the table with
-pointers to the symbols, and a trailing NULL. The routine returns the
-actual number of symbol pointers not including the NULL.
-
-
-     #define bfd_canonicalize_symtab(abfd, location) \
-          BFD_SEND (abfd, _bfd_canonicalize_symtab,\
-                       (abfd, location))
-
-   lisp
-
-`bfd_set_symtab'
-................
-
-   Provided a table of pointers to to symbols and a count, writes to
-the output BFD the symbols when closed.
-
-     boolean bfd_set_symtab(bfd *, asymbol **, unsigned int );
-
-`bfd_print_symbol_vandf'
-........................
-
-   Prints the value and flags of the symbol supplied to the stream
-file.
-
-     void bfd_print_symbol_vandf(PTR file, asymbol *symbol);
-
-`bfd_make_empty_symbol'
-.......................
-
-   This function creates a new `asymbol' structure for the BFD, and
-returns a pointer to it.
-
-   This routine is necessary, since each back end has private
-information surrounding the `asymbol'. Building your own `asymbol' and
-pointing to it will not create the private information, and will cause
-problems later on.
-
-
-     #define bfd_make_empty_symbol(abfd) \
-          BFD_SEND (abfd, _bfd_make_empty_symbol, (abfd))
-
-   lisp
-
-
-File: bfdinfo,  Node: Archives,  Next: Formats,  Prev: Symbols,  Up: Top
-
-Archives
-========
-
-   Gumby, you promised to write this bit...
-
-   Archives are supported in BFD in `archive.c'.
-
-   An archive is represented internally just like another BFD, with a
-pointer to a chain of contained BFDs. Archives can be created by
-opening BFDs, linking them together and attaching them as children to
-another BFD and then closing the parent BFD.
-
-`bfd_get_next_mapent'
-.....................
-
-   What this does
-
-     symindex bfd_get_next_mapent(bfd *, symindex, carsym **);
-
-`bfd_set_archive_head'
-......................
-
-   Used whilst processing archives. Sets the head of the chain of BFDs
-contained in an archive to NEW_HEAD. (see chapter on archives)
-
-     boolean bfd_set_archive_head(bfd *output, bfd *new_head);
-
-`bfd_get_elt_at_index'
-......................
-
-   Return the sub bfd contained within the archive at archive index n.
-
-     bfd * bfd_get_elt_at_index(bfd *, int);
-
-`bfd_openr_next_archived_file'
-..............................
-
-   Initially provided a BFD containing an archive and NULL, opens a BFD
-on the first contained element and returns that. Subsequent calls to
-bfd_openr_next_archived_file should pass the archive and the previous
-return value to return a created BFD to the next contained element. 
-NULL is returned when there are no more.
-
-     bfd* bfd_openr_next_archived_file(bfd *archive, bfd *previous);
-
-
-File: bfdinfo,  Node: Formats,  Next: Relocations,  Prev: Archives,  Up: Top
-
-File Formats
-============
-
-   A format is a BFD concept of high level file contents. The formats
-supported by BFD are:
-
-`bfd_object'
-     The BFD may contain data, symbols, relocations and debug info.
-
-`bfd_archive'
-     The 
\ No newline at end of file
diff --git a/bfd/doc/blins-p b/bfd/doc/blins-p
deleted file mode 100755
index 858dcd7..0000000
--- a/bfd/doc/blins-p
+++ /dev/null
@@ -1,8 +0,0 @@
-# sed script for BFD header files
-# Merge adjacent blank lines.  Loop til no change.
-:blin
-/^$/,/^ *[^ ]*.*$/{
-/^$/N
-s/^ *\n *$//
-}
-t blin
diff --git a/bfd/doc/exfil1-p b/bfd/doc/exfil1-p
deleted file mode 100755
index a57fc95..0000000
--- a/bfd/doc/exfil1-p
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# Locate and coalesce adjacent comments
-/\*\/$/N
-s/\*\/\n\/\*/\
-/
diff --git a/bfd/doc/exfil3-p b/bfd/doc/exfil3-p
deleted file mode 100755
index c557a16..0000000
--- a/bfd/doc/exfil3-p
+++ /dev/null
@@ -1,16 +0,0 @@
-# blank-line activity:
-# Merge adjacent blank lines.  Loop til no change.
-:blin
-/^$/,/^ *[^ ]*.*$/{
-/^$/N
-s/^ *\n *$//
-}
-t blin
-#
-/^$/,/^ *[^ ]*.*$/{
-/^$/N
-# Transpose <blank line> <end comment>
-/^ *\n\*\/$/c\
-*\/\
-
-}
diff --git a/bfd/doc/exfilter b/bfd/doc/exfilter
deleted file mode 100755
index 7551607..0000000
--- a/bfd/doc/exfilter
+++ /dev/null
@@ -1,14 +0,0 @@
-# SED script for preprocessing embedded doc from source (S. Chamberlain markup)
-# Final pass; cleanup work is done here.
-#
-# Within examples, make '{' and '}' printable:
-/^@lisp$/,/^@end lisp$/s/{/@{/
-/^@lisp$/,/^@end lisp$/s/}/@}/
-/^@example$/,/^@end example$/s/{/@{/
-/^@example$/,/^@end example$/s/}/@}/
-#
-# Delete empty @findex and @subsubsection entries (resulting from *proto*
-# with no further text on same line, in middle pass)
-/^@findex $/d
-/^@subsubsection @code{}/d
-#
diff --git a/bfd/doc/exfilter-p b/bfd/doc/exfilter-p
deleted file mode 100755
index 27a1d05..0000000
--- a/bfd/doc/exfilter-p
+++ /dev/null
@@ -1,12 +0,0 @@
-# SED script for preprocessing embedded headers from C source comments 
-# (S. Chamberlain markup)
-# beginning of many passes of cleanup work 
-#
-# Delete empty comment blocks
-/^\/\*$/N
-/^\/\*\n\*\/ *$/d
-#
-# Locate and coalesce adjacent comments
-/\*\/$/N
-s/\*\/\n\/\*/\
-/
diff --git a/bfd/doc/exfiltst b/bfd/doc/exfiltst
deleted file mode 100755
index 18bab5a..0000000
--- a/bfd/doc/exfiltst
+++ /dev/null
@@ -1,8 +0,0 @@
-# Merge adjacent blank lines.  Loop til no change.
-:blin
-/^$/,/^ *[^ ]*.*$/{
-/^$/N
-s/^ *\n *$//
-}
-t blin
-
diff --git a/bfd/doc/exmerge b/bfd/doc/exmerge
deleted file mode 100755
index dafa424..0000000
--- a/bfd/doc/exmerge
+++ /dev/null
@@ -1,4 +0,0 @@
-# SED script for preprocessing embedded doc from source (S. Chamberlain markup)
-# Locate and coalesce adjacent @example blocks
-/^@end example/N
-/^@end example\n@example$/d
diff --git a/bfd/doc/intobfd b/bfd/doc/intobfd
deleted file mode 100755
index f72d8e9..0000000
--- a/bfd/doc/intobfd
+++ /dev/null
@@ -1,13 +0,0 @@
-/\/\*:init.c\*\//r init.p
-/\/\*:archive.c\*\//r archive.p
-/\/\*:archures.c\*\//r archures.p
-/\/\*:bfd.c\*\//r bfd.p
-/\/\*:core.c\*\//r core.p
-/\/\*:format.c\*\//r format.p
-/\/\*:libbfd.c\*\//r libbfd.p
-/\/\*:opncls.c\*\//r opncls.p
-/\/\*:reloc.c\*\//r reloc.p
-/\/\*:section.c\*\//r section.p
-/\/\*:syms.c\*\//r syms.p
-/\/\*:targets.c\*\//r targets.p
-
diff --git a/bfd/doc/mergecom-p b/bfd/doc/mergecom-p
deleted file mode 100755
index 456478b..0000000
--- a/bfd/doc/mergecom-p
+++ /dev/null
@@ -1,5 +0,0 @@
-# SED script for preprocessing embedded headers from C source comments 
-# Locate and coalesce adjacent comments
-/\*\/$/N
-s/\*\/\n\/\*/\
-/
diff --git a/bfd/doc/movecom-p b/bfd/doc/movecom-p
deleted file mode 100755
index 7ed04c7..0000000
--- a/bfd/doc/movecom-p
+++ /dev/null
@@ -1,8 +0,0 @@
-# sed script for BFD header files:
-# Transpose <blank line> <end comment>
-/^$/,/^ *[^ ]*.*$/{
-/^$/N
-/^ *\n\*\/$/c\
-*\/\
-
-}
diff --git a/bfd/doc/scanit b/bfd/doc/scanit
deleted file mode 100755
index a989c78..0000000
--- a/bfd/doc/scanit
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/sh
-# Script to coordinate parsing of S. Chamberlain source-embedded 
-# documentation markup language.
-
-# Four passes:
-#	1) awk discards lines not intended for docn, and marks blocks of
-#	   text with comments identifying source file;
-#	2) first sed pass interprets Chamberlain markup;
-#	3) second sed pass does cleanup that involves merging lines
-#	4) third sed pass does remaining cleans up---making {}
-#	   printable within examples, and eliminating empty index entries and
-#          headings.
-#Third and second sed passes are separate because order of execution is hard
-#to control otherwise, making one or another of the things involving @example
-#inoperative.
-
-base=`echo $1 | cut -d '.' -f 1`
-out=`echo $2 | cut -d '.' -f 1`
-
-awk -f $3/awkscan $1 | \
-sed -f $3/sedscript | \
-sed -f $3/unPROTO | \
-sed -f $3/exmerge  | \
-sed -f $3/exfilter  >$out.texi
-
diff --git a/bfd/doc/scanph b/bfd/doc/scanph
deleted file mode 100755
index 956c2e9..0000000
--- a/bfd/doc/scanph
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/sh
-# Script to coordinate parsing of S. Chamberlain source-embedded 
-# header-file markup language. 
-
-# '-i' option means use *proto-internal* segments, else just *proto*
-SFX=p
-if [ $1 = "-i" ]; then
-	SFX=ip
-	shift
-fi
-
-out=`echo $2 | cut -d '.' -f 1`
-
-#  passes:
-#	1) awk discards lines not intended for header, and marks blocks of
-#	   text with comments identifying source file;
-#	2) first sed pass interprets Chamberlain markup;
-#	3) further sed passes clean up---merging adjacent comments etc.
-
-awk -f $3/awkscan-$SFX $1 |\
-sed -f $3/sedscript-p |\
-sed -f $3/mergecom-p |\
-sed -f $3/startcom-p  |\
-sed -f $3/blins-p |\
-sed -f $3/movecom-p  >$out.$SFX
diff --git a/bfd/doc/sedscript b/bfd/doc/sedscript
deleted file mode 100755
index cc2022c..0000000
--- a/bfd/doc/sedscript
+++ /dev/null
@@ -1,85 +0,0 @@
-# SED script for preprocessing embedded doc from source (S. Chamberlain markup)
-# middle pass; most of the work is done here.
-#
-# First, get rid of /*doc* markers; they've done their job in the first pass.
-/^\/\*doc\*/d
-#
-# /*proto* markers may be optionally followed by a *i-style subsubsec, findex
-# entry.  This will generate empty @findex and @subsubsection entries if
-# the *proto* is on a line by itself; third pass removes them.
-/^\/\*proto\*/s/^\/\*proto\* *\(.*\)$/@findex \1\
-@subsubsection @code{\1}/
-#
-# /*proto-internal* is just like /*proto* from doc point of view.
-/^\/\*proto-internal\*/s/^\/\*proto-internal\* *\(.*\)$/@findex \1\
-@subsubsection @code{\1}/
-#
-# *i at beginning of line: rest of line is both a subsubsection heading
-#   and an entry in function index.
-/^\*i/s/^\*i *\(.*\)$/@findex \1\
-@subsubsection @code{\1}/
-#
-# Two alternative docn block ends, '*/' and '*-*/' on lines by themselves;
-# replace by blank lines (for texinfo source readability).
-/^\*\/$/c\
-
-/^\*-\*\/$/c\
-
-# {* and *} are standins for comment markers (originally embedded in .c 
-# comments)---turn into real comment markers:
-s/{\*/\/\*/
-s/\*}/\*\//
-#
-# '*+++' and '*---' span a block of text that includes both example lines 
-# (marked by leading '$') and explanatory text (to be italicized).
-# Italicize lines lacking '$':
-/\*\+\+\+/,/\*---/s/^\([^$].*\)$/@i{\1}/
-#
-# We don't need *+++ and *--- markers any more; kill them (trailing marker
-# becomes blank line for readability)
-/\*\+\+\+/d
-/\*---/c\
-
-# Any line beginning with '$' is made an example line; third pass later 
-# coalesces adjacent example blocks.  *DO NOT* introduce extra space after
-# @end example, so we can spot adjacent ones in third pass.
-/^\$/i\
-@example
-/^\$/a\
-@end example
-#
-# In any example line, turn '{' and '}' into '@{' and '@}'
-###/^\$/s/{/@{/g
-###/^\$/s/}/@}/g
-#
-# Now delete the '$' markers themselves:
-/^\$/s/\$//
-#
-# *+ and *- delimit large examples to be enclosed in cartouches.
-/^\*\+$/c\
-@lisp\
-@c @cartouche
-/^\*-$/c\
-@c @end cartouche\
-@end lisp\
-
-# '*;' introduces an example which may have a single line or multiple lines;
-# it extends until the next semicolon (which is also printed).
-# One-line case: (do this first; else second line address for multi-line case
-# will include random text til we happen to end a line in a doc comment with
-# a semicolon)
-/^\*;.*;$/{
-s/^\*;/@example\
-/
-s/;$/;\
-@end example\
-/
-}
-# Multi-line case:
-/^\*;/,/.*;$/{
-s/^\*;/@example\
-/
-s/;$/;\
-@end example\
-/
-}
diff --git a/bfd/doc/sedscript-p b/bfd/doc/sedscript-p
deleted file mode 100755
index 1f24900..0000000
--- a/bfd/doc/sedscript-p
+++ /dev/null
@@ -1,63 +0,0 @@
-# SED script for preprocessing embedded headers from source 
-# (S. Chamberlain markup)
-# middle pass; most of the work is done here.
-#
-# First, get rid of /*proto* markers; they've done their job in the first pass.
-# (They remain comment-introducers)
-/^\/\*proto\*/s/^\/\*proto\*/\/*/
-/^\/\*proto-internal\*/s/^\/\*proto-internal\*/\/*/
-#
-# *-*/ is an alternative (older) comment-block end.  Remap for uniformity:
-s/^\*-\*\//\*\//
-#
-# {* and *} are standins for comment markers (originally embedded in .c 
-# comments)---turn into real comment markers:
-s/{\*/\/\*/
-s/\*}/\*\//
-#
-# '*+++' and '*---' span a block of text that includes both header lines 
-# (marked by leading '$') and explanatory text (to be comments).
-# No need to start comment at "*+++", or end it at "*---", since we're 
-# already in a *proto* comment block.  Just delete.
-/\*\+\+\+/d
-/\*---/d
-#
-# Any line beginning with '$' is made a line of code in the header; 
-#  stuff in between is comments, so *precede* each '$' line with 
-#  END-comment, *follow* each '$' line with START-comment; third pass later 
-#  eliminates empty comment blocks.
-/^\$/i\
-*/
-/^\$/a\
-/*
-#
-# Now delete the '$' markers themselves:
-/^\$/s/\$//
-#
-# *+ and *- delimit larger blocks of code, treated the same as '$' lines
-/^\*\+$/c\
-*/
-/^\*-$/c\
-/*
-#
-# '*;' introduces code which may have a single line or multiple lines;
-# it extends until the next semicolon (which is also printed).
-#
-# One-line case: (do this first; else second line address for multi-line case
-# will include random text til we happen to end a line in a proto comment with
-# a semicolon)
-/^\*;.*;$/{
-s/^\*;/*\/\
-/
-s/;$/;\
-\/*\
-/
-}
-# Multi-line case:
-/^\*;/,/.*;$/{
-s/^\*;/*\/\
-/
-s/;$/;\
-\/*\
-/
-}
diff --git a/bfd/doc/startcom-p b/bfd/doc/startcom-p
deleted file mode 100755
index 0748fad..0000000
--- a/bfd/doc/startcom-p
+++ /dev/null
@@ -1,12 +0,0 @@
-# sed script for preprocessing BFD header files
-# <start comment> activity:
-/^\/\*$/{
-N
-# Delete empty comment blocks
-/^\/\*\n\*\/ *$/d
-# Transpose <start comment><blank line>
-s/^\/\*\n *$/\
-\/*/
-# merge <start comment> on line by itself with following line
-s/^\/\*\n\(.*\)/\/* \1/
-}
diff --git a/bfd/doc/tolibbfd b/bfd/doc/tolibbfd
deleted file mode 100755
index 3caa5eb..0000000
--- a/bfd/doc/tolibbfd
+++ /dev/null
@@ -1,10 +0,0 @@
-/---------------START FROM/,/---------------END FROM/d
-/\/\*:init.c\*\//r init.ip
-/\/\*:libbfd.c\*\//r libbfd.ip
-/\/\*:cache.c\*\//r cache.ip
-/\/\*:cpu-h8300.c\*\//r cpu-h8300.ip
-/\/\*:cpu-i960.c\*\//r cpu-i960.ip
-/\/\*:cpu-empty.c\*\//r cpu-empty.ip
-/\/\*:archures.c\*\//r archures.ip
-/\/\*:reloc.c\*\//r reloc.ip
-/\/\*:ctor.c\*\//r ctor.ip
diff --git a/bfd/doc/tolibcoff b/bfd/doc/tolibcoff
deleted file mode 100755
index 548c8ba..0000000
--- a/bfd/doc/tolibcoff
+++ /dev/null
@@ -1 +0,0 @@
-/\/\*:coffcode.h\*\//r coffcode.p
diff --git a/bfd/doc/unPROTO b/bfd/doc/unPROTO
deleted file mode 100755
index a6f9520..0000000
--- a/bfd/doc/unPROTO
+++ /dev/null
@@ -1,18 +0,0 @@
-#
-# The PROTO macro is a subterfuge to be compatible with both ANSI and K&R 
-# declaration syntax.  It's not widely known, so for the docn just map the 
-# thing to ANSI declaration syntax.
-# 
-# First, join up defns broken across multiple lines in source---but leave
-# any linebreaks, to prettify our examples 
-:pbegn
-/PROTO(.*, *$/N
-s/\n/?/
-t pbegn
-s/?/\
-/g
-# Now actually do the PROTO interpretation.
-# A PROTO invocation looks like
-#   PROTO( resulttype, function, (arglist));
-s/[ 	]*PROTO(\(.*\),[\n 	]*\(.*\),[\n 	]*\((.*)\));/\1 \2\3;/
-