Initial revision

2 files changed, 674 insertions, 0 deletions

diff --git a/bfd/bfd.texinfo b/bfd/bfd.texinfo
new file mode 100755
index 0000000..a88f819
--- /dev/null
+++ b/bfd/bfd.texinfo
@@ -0,0 +1,430 @@
+\input cyginfo
+@c\input texinfo 
+@setfilename bfdinfo
+@c $Id$
+@synindex ky cp
+@ifinfo
+This file documents the BFD library.
+
+Copyright (C) 1991 Cygnus Support.
+
+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.
+
+@ignore
+Permission is granted to process this file through Tex and print the
+results, provided the printed document carries copying permission
+notice identical to this one except for the removal of this paragraph
+(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, provided also that the
+section entitled ``GNU General Public License'' is included exactly as
+in the original, and provided 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,
+except that the section entitled ``GNU General Public License'' may be
+included in a translation approved by the author instead of in the
+original English.
+@end ifinfo
+@iftex
+@c this removes the gaps around @examples
+
+@c@finalout
+@c@setchapternewpage odd
+@settitle LIB BFD, the Binary File Desciptor Library
+@titlepage
+@title{libbfd}
+@subtitle{The Big File Descriptor Library}
+@sp 1
+@subtitle First Edition---@code{bfd} version < 2.0
+@subtitle April 1991
+@author {Steve Chamberlain}
+@author {Cygnus Support}
+@page
+
+@tex
+\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 {\it BFD}, \manvers\par
+\hfill \TeX{}info \texinfoversion\par
+}
+\global\parindent=0pt % Steve likes it this way
+@end tex
+
+@vskip 0pt plus 1filll
+Copyright @copyright{} 1991 Cygnus Support.
+
+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, provided also 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 titlepage
+@end iftex
+@c FIXME: Talk about importance of *order* of args, cmds to linker!
+
+@node Top, Overview, (dir), (dir)
+@ifinfo
+This file documents the binary file descriptor library libbfd.
+@end ifinfo
+
+@menu
+* Overview::			Overview of bfd
+* History::			History of bfd
+* Backends::			Backends
+* Porting::			Porting
+* Future::			Future
+* Index::			Index
+
+BFD body:
+* Sections::
+* Symbols::
+* Archives::
+* Formats::
+* Relocations::
+* Core Files::
+* Targets::
+* Architecturs::
+* Opening and Closing::
+* Internal::
+* File Caching::
+
+Bfd backends:
+* a.out backends::
+* coff backends::
+@end menu
+
+@node Overview, History, Top, Top
+@chapter Introduction
+@cindex BFD
+@cindex what is it?
+Simply put, @code{bfd} is a package which allow 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.
+@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.
+@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
+their own use, for greater efficiency.
+@end itemize
+@node History, How It Works, Overview,Top
+@section History
+
+Gumby really knows this, so his bit goes here.
+One spur behind @code{bfd} was the Intel Oregon's GNU 960 team desire for
+interoperability of applications on their COFF and b.out file formats.
+Cygnus was providing GNU support for the team, and Cygnus were
+contracted to provid the required functionality.
+
+The name came from a conversation Gumby Wallace was
+having with Richard Stallman about the library, RMS said that it
+would be quite hard, Gumby 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
+Gumby Wallace (gumby@@cygnus.com).
+
+@node How It Works, History, Porting, Top
+@section How It Works
+@code{bfd} provides a common interface to the parts of an object file
+to 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 structure described in
+@code{include/bfd.h}, called @code{bfd}. Conventionally this pointer is
+called a @code{bfd}, and instances of it within code are called
+@code{abfd}. All operations on the target object file are applied as
+methods to the @code{bfd}, the mapping is defined within @code{bfd.h} in
+a set of macros, all beginning @code{bfd}_something. 
+
+For example, this sequence would do what you expect:
+@tex
+\globaldefs=1
+\def\example{\begingroup\inENV %This group ends at the end of the @lisp body
+\hfuzz=12truept % Don't be fussy
+% Make spaces be word-separators rather than space tokens.
+\sepspaces %
+% Single space lines
+\singlespace %
+% The following causes blank lines not to be ignored
+% by adding a space to the end of each line.
+\let\par=\lisppar
+\def\Eexample{\endgroup}%
+\parskip=0pt
+\advance \leftskip by \lispnarrowing
+\parindent=0pt
+\let\exdent=\internalexdent
+\obeyspaces \obeylines \tt \rawbackslash
+\def\next##1{}\next}
+\globaldefs=0
+@end tex
+
+@lisp
+@w{
+#include "bfd.h"
+
+unsigned int number_of_sections(abfd)
+bfd *abfd;
+@{
+  return bfd_count_sections(abfd);
+@}
+}
+@end lisp
+
+The metaphor used within @code{bfd} is that an object file has a header,
+a numbber of sections containing raw data, a set of relocations and some
+symbol information. Also, @code{bfd}s opened upon archives have the
+additional attribute of an index and contained sub bfds. This approach is
+find for a.out and coff, but looses efficiency when applied to formats
+such as S-records and IEEE-695. 
+
+@section What BFD Version 1 Can't 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 common form. When the link is
+finished and the linker writes the symbol table of the output file,
+another BFD back end routine is called which takes the newly
+created symbol table and converts it into the chosen output format.
+
+@node BFD information loss, Mechanism, BFD outline, BFD
+@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 using the linker to read one
+ format and write 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 linker. 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 big endian COFF to little endian COFF, or from @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, BFD
+@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.
+
+@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 and may be thrown away with
+appropriate command line switches. (The GNU debugger @code{gdb} does
+support @code{a.out} style debugging information in COFF).
+
+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
+
+
+What is a backend
+@node BFD front end, BFD back end, Mechanism, Top
+@page
+@chapter BFD front end
+@include doc/bfd.doc
+@page
+@node Sections, Symbols , bfd, Top
+@include doc/section.doc
+@page
+@node Symbols, Archives ,Sections, To
+@include doc/syms.doc
+@page
+@node Archives, Formats, Symbols, Top
+@include doc/archive.doc
+@page
+@node Formats, Relocations, Archives, Top
+@include doc/format.doc
+@page
+@node Relocations, Core Files,Formats, Top
+@include doc/reloc.doc
+@page
+@node Core Files, Targets,  Relocations, Top
+@include doc/core.doc
+@page
+@node Targets, Architectures, Core Files, Top
+@include doc/targets.doc
+@page
+@node Architectures, Opening and Closing, Targets, Top
+@include doc/archures.doc
+@page
+@node Opening and Closing, Internal, Architectures, Top
+@include doc/opncls.doc
+@page
+@node Internal, File Caching, Opening and Closing, Top
+@include doc/libbfd.doc
+@page
+@node File Caching, Top, Internal, Top
+@include doc/cache.doc
+@page
+@chapter BFD back end
+@node BFD back end, ,BFD front end, Top
+@menu
+* What to put where
+* a.out backends::
+* coff backends::
+* oasys backend::
+* ieee backend::
+* srecord backend::
+@end menu
+@node What to Put Where, aout backends, BFD back end, BFD back end
+All of bfd lives in one directory.
+@page
+@node aout backends, coff backends, What to Put Where, BFD back end
+@include doc/aoutx.doc
+@page
+@node coff backends, oasys backends, aout backends, BFD back end
+@include doc/coffcode.doc
+@page
+@node Index,  , BFD, Top
+@unnumbered Function Index
+@printindex  fn
+@setchapternewpage on
+@unnumbered Index
+@printindex cp
+
+@tex
+% I think something like @colophon should be in texinfo.  In the
+% meantime:
+\long\def\colophon{\hbox to0pt{}\vfill
+\centerline{The body of this manual is set in}
+\centerline{\fontname\tenrm,}
+\centerline{with headings in {\bf\fontname\tenbf}}
+\centerline{and examples in {\tt\fontname\tentt}.}
+\centerline{{\it\fontname\tenit\/} and}
+\centerline{{\sl\fontname\tensl\/}}
+\centerline{are used for emphasis.}\vfill}
+\page\colophon
+% Blame: pesch@cygnus.com, 28mar91.
+@end tex
+
+
+@contents
+@bye
+
+
diff --git a/bfd/coff-a29k.c b/bfd/coff-a29k.c
new file mode 100644
index 0000000..c52f6f1
--- /dev/null
+++ b/bfd/coff-a29k.c
@@ -0,0 +1,244 @@
+/* Copyright (C) 1990, 1991 Free Software Foundation, Inc.
+   Contributed by David Wood at New York University 7/8/91
+
+This file is part of BFD, the Binary File Diddler.
+
+BFD is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 1, or (at your option)
+any later version.
+
+BFD is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with BFD; see the file COPYING.  If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+
+
+/* $Id$ */
+
+#define A29K 1
+
+#include <ansidecl.h>
+#include <sysdep.h>
+#include "bfd.h"
+#include "libbfd.h"
+#include "obstack.h"
+#include "amdcoff.h"
+#include "internalcoff.h"
+#include "libcoff.h"
+
+#define INSERT_HWORD(WORD,HWORD)	\
+	(((WORD) & 0xff00ff00) | (((HWORD) & 0xff00) << 8) | ((HWORD)& 0xff))
+#define EXTRACT_HWORD(WORD) 	(((WORD) & 0x00ff0000) >> 8) | ((WORD) & 0xff)
+
+/* Provided the symbol, returns the value reffed */
+static  long
+get_symbol_value(symbol)       
+asymbol *symbol;
+{                                             
+  long relocation = 0;
+
+  if (symbol != (asymbol *)NULL) {              
+    if (symbol->flags & BSF_FORT_COMM) {        
+      relocation = 0;                           
+    } else {                                      
+      relocation = symbol->value;               
+    }                                           
+    if (symbol->section != (asection *)NULL) {    
+      relocation += symbol->section->output_section->vma +
+        	symbol->section->output_offset;           
+    }                                             
+  }
+  return(relocation);
+}
+
+static bfd_reloc_status_enum_type
+a29k_reloc(abfd, reloc_entry, symbol_in, data, input_section)
+bfd *abfd;
+arelent *reloc_entry;
+asymbol *symbol_in;
+unsigned char *data;
+asection *input_section;
+{
+	static unsigned long part1_consth_active=0;
+	static unsigned long part1_consth_value;
+	unsigned long insn, value, sym_value; 
+	unsigned short r_type;
+/*  	bfd_reloc_status_enum_type result;*/
+/*  	coff_symbol_type *cs = coffsymbol(symbol_in);*/
+	
+	r_type = reloc_entry->howto->type;
+
+        /* FIXME: Do we need to check for partial linking here */
+        if (symbol_in && (symbol_in->flags & BSF_UNDEFINED)) {
+		/* Keep the state machine happy in case we're called again */
+		if (r_type == R_IHIHALF) {
+			part1_consth_active = 1;
+			part1_consth_value  = 0;
+		}
+                return(bfd_reloc_undefined);
+	}
+
+	if ((part1_consth_active) && (r_type != R_IHCONST)) {
+		fprintf(stderr,"Relocation problem : ");
+		fprintf(stderr,"Missing IHCONST in module %s\n",abfd->filename);
+		part1_consth_active = 0;
+		return(bfd_reloc_dangerous);
+	}
+
+	insn = bfd_get_32(abfd, data + reloc_entry->address); 
+	sym_value = get_symbol_value(symbol_in);
+
+	switch (r_type) {
+	case R_IREL: 	
+		value = EXTRACT_HWORD(insn) << 2;
+		value +=  sym_value + reloc_entry->addend;
+		if (value <= 0x3ffff) {		/* Absolute jmp/call */
+			insn |= 0x01000000;	/* Make it absolute */
+			/* FIXME: Should we change r_type to R_IABS */
+		} else {			/* Relative jmp/call */
+			value -= reloc_entry->address;
+			if (value > 0x3ffff) {
+				fprintf(stderr,"Relocation problem : ");
+				fprintf(stderr,"Jmp/call too far; to %d from %s\n",
+					symbol_in->name,abfd->filename); 
+				return(bfd_reloc_outofrange);
+			}
+		}
+		value >>= 2;
+		insn = INSERT_HWORD(insn,value);
+		break;
+	case R_ILOHALF: 
+		value = EXTRACT_HWORD(insn);
+		value +=  sym_value + reloc_entry->addend;
+		insn = INSERT_HWORD(insn,value);
+		break;
+	case R_IHIHALF: 	/* consth, part 1 */
+		/* Just get the symbol value that is referenced */
+		part1_consth_active = 1;
+		part1_consth_value = sym_value + reloc_entry->addend;
+		return(bfd_reloc_ok);	/* Don't modify insn until R_IHCONST */
+		break;
+	case R_IHCONST: 	/* consth, part 2 */
+		/* Now relocate the reference */
+		if (!part1_consth_active) {
+			fprintf(stderr,"Relocation problem : ");
+			fprintf(stderr,"IHIHALF missing in module %s\n",
+				abfd->filename); 
+			part1_consth_active = 0;
+			return(bfd_reloc_dangerous);
+		}
+		/* sym_ptr_ptr = r_symndx, in coff_slurp_reloc_table() */
+		value = (unsigned int)reloc_entry->addend; /* r_symndx */
+		value += part1_consth_value;
+		value >>= 16;
+		insn = INSERT_HWORD(insn,value);
+		part1_consth_active = 0;
+		break;
+	case R_BYTE:
+		value = (insn >> 24) + sym_value + reloc_entry->addend;	
+		if (value & 0xffffff00) {
+			fprintf(stderr,"Relocation problem : ");
+			fprintf(stderr,"byte value too large in module %s\n",
+				abfd->filename); 
+			return(bfd_reloc_overflow);
+		}
+		insn = (insn & 0x00ffffff) | (value << 24);
+		break;
+	case R_HWORD:
+		value = (insn >> 16) + sym_value + reloc_entry->addend;	
+		if (value & 0xffff0000) {
+			fprintf(stderr,"Relocation problem : ");
+			fprintf(stderr,"hword value too large in module %s\n",
+				abfd->filename); 
+			return(bfd_reloc_overflow);
+		}
+		insn = (insn & 0x0000ffff) | (value<<16); 
+		break;
+	case R_WORD:
+		insn += sym_value + reloc_entry->addend;  
+		break;
+	default:
+		fprintf(stderr,"Relocation problem : ");
+		fprintf(stderr,"Unrecognized reloc type %d, in module %s\n",
+				r_type,abfd->filename); 
+		return (bfd_reloc_dangerous);
+	}
+
+	bfd_put_32(abfd, insn, data+reloc_entry->address);
+	return(bfd_reloc_ok);	
+}
+
+/*      type	   rightshift
+		       size
+			  bitsize
+			       pc-relative
+				     bitpos
+					 absolute
+					     complain_on_overflow
+						  special_function
+						    relocation name
+							       partial_inplace 
+								      src_mask
+*/
+
+/*FIXME: I'm not real sure about this table */
+#define NA	0	/* Obsolete fields, via the documentation */
+static reloc_howto_type howto_table[] = 
+{
+  {R_ABS,     0, 3, NA, false, NA, NA, true,a29k_reloc,"ABS",     true, 0xffffffff,0xffffffff, false},
+  {1},  {2},  {3},   {4},  {5},  {6},  {7},  {8},  {9}, {10},
+  {11}, {12}, {13}, {14}, {15}, {16}, {17}, {18}, {19}, {20},
+  {21}, {22}, {23},
+  {R_IREL,    0, 3, NA, true,  NA, NA, true,a29k_reloc,"IREL",    true, 0xffffffff,0xffffffff, false},
+  {R_IABS,    0, 3, NA, false, NA, NA, true,a29k_reloc,"IABS",    true, 0xffffffff,0xffffffff, false},
+  {R_ILOHALF, 0, 3, NA, true,  NA, NA, true,a29k_reloc,"ILOHALF", true, 0x0000ffff,0x0000ffff, false},
+  {R_IHIHALF, 0, 3, NA, true,  NA, NA, true,a29k_reloc,"IHIHALF", true, 0xffff0000,0xffff0000, false},
+  {R_IHCONST, 0, 3, NA, true,  NA, NA, true,a29k_reloc,"IHCONST", true, 0xffff0000,0xffff0000, false},
+  {R_BYTE,    0, 0, NA, false, NA, NA, true,a29k_reloc,"BYTE",    true, 0x000000ff,0x000000ff, false},
+  {R_HWORD,   0, 1, NA, false, NA, NA, true,a29k_reloc,"HWORD",   true, 0x0000ffff,0x0000ffff, false},
+  {R_WORD,    0, 2, NA, false, NA, NA, true,a29k_reloc,"WORD",    true, 0xffffffff,0xffffffff, false},
+};
+#undef NA
+
+#define BADMAG(x) A29KBADMAG(x)
+
+#include "coffcode.h"
+
+bfd_target a29kcoff_big_vec =
+{
+  "coff-a29k-big",		/* name */
+  bfd_target_coff_flavour_enum,
+  true,				/* data byte order is big */
+  true,				/* header byte order is big */
+
+  (HAS_RELOC | EXEC_P |		/* object flags */
+   HAS_LINENO | HAS_DEBUG |
+   HAS_SYMS | HAS_LOCALS | DYNAMIC | WP_TEXT),
+
+  (SEC_HAS_CONTENTS | SEC_ALLOC /* section flags */
+	| SEC_LOAD | SEC_RELOC  
+	| SEC_READONLY ),
+  '/',				/* ar_pad_char */
+  15,				/* ar_max_namelen */
+
+     3,				/* minimum section alignment */
+_do_getb64, _do_putb64,  _do_getb32, _do_putb32, _do_getb16, _do_putb16, /* data */
+_do_getb64, _do_putb64,  _do_getb32, _do_putb32, _do_getb16, _do_putb16, /* hdrs */
+
+
+  {_bfd_dummy_target, coff_object_p, /* bfd_check_format */
+     bfd_generic_archive_p, _bfd_dummy_target},
+  {bfd_false, coff_mkobject, _bfd_generic_mkarchive, /* bfd_set_format */
+     bfd_false},
+  {bfd_false, coff_write_object_contents,	/* bfd_write_contents */
+     _bfd_write_archive_contents, bfd_false},
+
+     JUMP_TABLE(coff),
+     COFF_SWAP_TABLE
+  };
+