* doc/Makefile.in (TEXI2DVI): Set to just name of program.

	(DVIPS): Set to dvips.
	(ps, as.ps, gasp.ps): New targets.
	(internals.info, gasp.dvi, internals.dvi): Set both TEXINPUTS
 	and MAKEINFO env variables.
	(internals.ps): Use DVIPS macro.
	(clean): Remove core and backup files.
	(distclean): Remove temporary files from building internals.
	(clean-dvi): Ditto.
	* doc/internals.texi (Frags): Fix typo.
	(GAS processing): Ditto.
	(CPU backend): Ditto.
	* ecoff.c (init_file): Use TARGET_BYTES_BIG_ENDIAN value directly.
	* mpw-config.in: Define TARGET_BYTES_BIG_ENDIAN as 1.
	* read.c: Remove ugly hack that dealt with config files not
	correctly defining TARGET_BYTES_BIG_ENDIAN.
	(target_big_endian): Use TARGET_BYTES_BIG_ENDIAN directly.
	* config/arm-big.mt: Define TARGET_BYTES_BIG_ENDIAN to 1.
	* config/arm-lit.mt: Define TARGET_BYTES_BIG_ENDIAN to 0.
	* config/mips-big.mt: Define TARGET_BYTES_BIG_ENDIAN to 1.
	* config/mips-lit.mt: Define TARGET_BYTES_BIG_ENDIAN to 0.
	* config/ppc-lit.mt: Define TARGET_BYTES_BIG_ENDIAN to 1.
	* config/ppc-sol.mt: Replace TARGET_BYTES_LITTLE_ENDIAN
	with TARGET_BYTES_BIG_ENDIAN defined to 0.
	* config/tc-arm.h: Remove use of TARGET_BYTES_LITTLE_ENDIAN
	and simplify.  Test value of TARGET_BYTES_BIG_ENDIAN, not just
	whether it is defined or not.
	* config/tc-mips.h: Remove use of TARGET_BYTES_LITTLE_ENDIAN.
	* config/tc-ppc.h: Remove use of TARGET_BYTES_LITTLE_ENDIAN
	and simplify. Test value of TARGET_BYTES_BIG_ENDIAN, not just
	whether it is defined or not.
start-sanitize-tic80
	* config/tic80.h (TARGET_FORMAT): Define to coff-tic80.
	(TARGET_BYTES_BIG_ENDIAN): Define to 0.
end-sanitize-tic80

1 files changed, 1145 insertions, 391 deletions

diff --git a/gas/doc/internals.texi b/gas/doc/internals.texi
index 1ba9cfe..9c418db 100644
--- a/gas/doc/internals.texi
+++ b/gas/doc/internals.texi
@@ -1,52 +1,133 @@
 \input texinfo
 @setfilename internals.info
-@node Assembler Internals
-@chapter Assembler Internals
+@node Top
+@top Assembler Internals
+@raisesections
 @cindex internals
 
-This documentation is not ready for prime time yet.  Not even close.  It's not
-so much documentation as random blathering of mine intended to be notes to
-myself that may eventually be turned into real documentation.
+This chapter describes the internals of the assembler.  It is incomplete, but
+it may help a bit.
 
-I take no responsibility for any negative effect it may have on your
-professional, personal, or spiritual life.  Read it at your own risk.  Caveat
-emptor.  Delete before reading.  Abandon all hope, ye who enter here.
-
-However, enhancements will be gratefully accepted.
+This chapter was last modified on $Date$.  It is not updated regularly, and it
+may be out of date.
 
 @menu
+* GAS versions::        GAS versions
 * Data types::		Data types
+* GAS processing::      What GAS does when it runs
+* Porting GAS::         Porting GAS
+* Relaxation::          Relaxation
+* Broken words::        Broken words
+* Internal functions::  Internal functions
+* Test suite::          Test suite
+@end menu
+
+@node GAS versions
+@section GAS versions
+
+GAS has acquired layers of code over time.  The original GAS only supported the
+a.out object file format, with three sections.  Support for multiple sections
+has been added in two different ways.
+
+The preferred approach is to use the version of GAS created when the symbol
+@code{BFD_ASSEMBLER} is defined.  The other versions of GAS are documented for
+historical purposes, and to help anybody who has to debug code written for
+them.
+
+The type @code{segT} is used to represent a section in code which must work
+with all versions of GAS.
+
+@menu
+* Original GAS::        Original GAS version
+* MANY_SEGMENTS::       MANY_SEGMENTS gas version
+* BFD_ASSEMBLER::       BFD_ASSEMBLER gas version
 @end menu
 
-@node foo
-@section foo
+@node Original GAS
+@subsection Original GAS
+
+The original GAS only supported the a.out object file format with three
+sections: @samp{.text}, @samp{.data}, and @samp{.bss}.  This is the version of
+GAS that is compiled if neither @code{BFD_ASSEMBLER} nor @code{MANY_SEGMENTS}
+is defined.  This version of GAS is still used for the m68k-aout target, and
+perhaps others.
+
+This version of GAS should not be used for any new development.
 
-BFD_ASSEMBLER
-BFD, MANY_SECTIONS, BFD_HEADERS
+There is still code that is specific to this version of GAS, notably in
+@file{write.c}.  There is no way for this code to loop through all the
+sections; it simply looks at global variables like @code{text_frag_root} and
+@code{data_frag_root}.
 
+The type @code{segT} is an enum.
+
+@node MANY_SEGMENTS
+@subsection MANY_SEGMENTS gas version
+@cindex MANY_SEGMENTS
+
+The @code{MANY_SEGMENTS} version of gas is only used for COFF.  It uses the BFD
+library, but it writes out all the data itself using @code{bfd_write}.  This
+version of gas supports up to 40 normal sections.  The section names are stored
+in the @code{seg_name} array.  Other information is stored in the
+@code{segment_info} array.
+
+The type @code{segT} is an enum.  Code that wants to examine all the sections
+can use a @code{segT} variable as loop index from @code{SEG_E0} up to but not
+including @code{SEG_UNKNOWN}.
+
+Most of the code specific to this version of GAS is in the file
+@file{config/obj-coff.c}, in the portion of that file that is compiled when
+@code{BFD_ASSEMBLER} is not defined.
+
+This version of GAS is still used for several COFF targets.
+
+@node BFD_ASSEMBLER
+@subsection BFD_ASSEMBLER gas version
+@cindex BFD_ASSEMBLER
+
+The preferred version of GAS is the @code{BFD_ASSEMBLER} version.  In this
+version of GAS, the output file is a normal BFD, and the BFD routines are used
+to generate the output.
+
+@code{BFD_ASSEMBLER} will automatically be used for certain targets, including
+those that use the ELF, ECOFF, and SOM object file formats, and also all Alpha,
+MIPS, PowerPC, and SPARC targets.  You can force the use of
+@code{BFD_ASSEMBLER} for other targets with the configure option
+@samp{--enable-bfd-assembler}; however, it has not been tested for many
+targets, and can not be assumed to work.
 
 @node Data types
 @section Data types
 @cindex internals, data types
 
+This section describes some fundamental GAS data types.
+
+@menu
+* Symbols::             The symbolS structure
+* Expressions::         The expressionS structure
+* Fixups::		The fixS structure
+* Frags::               The fragS structure
+@end menu
+
+@node Symbols
 @subsection Symbols
 @cindex internals, symbols
 @cindex symbols, internal
-
-... `local' symbols ... flags ...
+@cindex symbolS structure
 
 The definition for @code{struct symbol}, also known as @code{symbolS}, is
-located in @file{struc-symbol.h}.  Symbol structures can contain the following
+located in @file{struc-symbol.h}.  Symbol structures contain the following
 fields:
 
 @table @code
 @item sy_value
 This is an @code{expressionS} that describes the value of the symbol.  It might
-refer to another symbol; if so, its true value may not be known until
-@code{foo} is called.
+refer to one or more other symbols; if so, its true value may not be known
+until @code{resolve_symbol_value} is called in @code{write_object_file}.
 
-More generally, however, ... undefined? ... or an offset from the start of a
-frag pointed to by the @code{sy_frag} field.
+The expression is often simply a constant.  Before @code{resolve_symbol_value}
+is called, the value is the offset from the frag (@pxref{Frags}).  Afterward,
+the frag address has been added in.
 
 @item sy_resolved
 This field is non-zero if the symbol's value has been completely resolved.  It
@@ -65,24 +146,29 @@ symbol list.
 @itemx sy_previous
 These pointers to other @code{symbolS} structures describe a singly or doubly
 linked list.  (If @code{SYMBOLS_NEED_BACKPOINTERS} is not defined, the
-@code{sy_previous} field will be omitted.)  These fields should be accessed
-with @code{symbol_next} and @code{symbol_previous}.
+@code{sy_previous} field will be omitted; @code{SYMBOLS_NEED_BACKPOINTERS} is
+always defined if @code{BFD_ASSEMBLER}.)  These fields should be accessed with
+the @code{symbol_next} and @code{symbol_previous} macros.
 
 @item sy_frag
-This points to the @code{fragS} that this symbol is attached to.
+This points to the frag (@pxref{Frags}) that this symbol is attached to.
 
 @item sy_used
 Whether the symbol is used as an operand or in an expression.  Note: Not all of
 the backends keep this information accurate; backends which use this bit are
 responsible for setting it when a symbol is used in backend routines.
 
+@item sy_mri_common
+Whether the symbol is an MRI common symbol created by the @code{COMMON}
+pseudo-op when assembling in MRI mode.
+
 @item bsym
-If @code{BFD_ASSEMBLER} is defined, this points to the @code{asymbol} that will
-be used in writing the object file.
+If @code{BFD_ASSEMBLER} is defined, this points to the BFD @code{asymbol} that
+will be used in writing the object file.
 
 @item sy_name_offset
 (Only used if @code{BFD_ASSEMBLER} is not defined.)  This is the position of
-the symbol's name in the symbol table of the object file.  On some formats,
+the symbol's name in the string table of the object file.  On some formats,
 this will start at position 4, with position 0 reserved for unnamed symbols.
 This field is not used until @code{write_object_file} is called.
 
@@ -106,29 +192,239 @@ by that name is defined in @file{targ-cpu.h}, this field is not defined.
 If this macro is defined, it defines additional fields in the symbol structure.
 This macro is obsolete, and should be replaced when possible by uses of
 @code{OBJ_SYMFIELD_TYPE} and @code{TC_SYMFIELD_TYPE}.
-
 @end table
 
-Access with S_SET_SEGMENT, S_SET_VALUE, S_GET_VALUE, S_GET_SEGMENT, etc., etc.
+There are a number of access routines used to extract the fields of a
+@code{symbolS} structure.  When possible, these routines should be used rather
+than referring to the fields directly.  These routines will work for any GAS
+version.
 
+@table @code
+@item S_SET_VALUE
+@cindex S_SET_VALUE
+Set the symbol's value.
+
+@item S_GET_VALUE
+@cindex S_GET_VALUE
+Get the symbol's value.  This will cause @code{resolve_symbol_value} to be
+called if necessary, so @code{S_GET_VALUE} should only be called when it is
+safe to resolve symbols (i.e., after the entire input file has been read and
+all symbols have been defined).
+
+@item S_SET_SEGMENT
+@cindex S_SET_SEGMENT
+Set the section of the symbol.
+
+@item S_GET_SEGMENT
+@cindex S_GET_SEGMENT
+Get the symbol's section.
+
+@item S_GET_NAME
+@cindex S_GET_NAME
+Get the name of the symbol.
+
+@item S_SET_NAME
+@cindex S_SET_NAME
+Set the name of the symbol.
+
+@item S_IS_EXTERNAL
+@cindex S_IS_EXTERNAL
+Return non-zero if the symbol is externally visible.
+
+@item S_IS_EXTERN
+@cindex S_IS_EXTERN
+A synonym for @code{S_IS_EXTERNAL}.  Don't use it.
+
+@item S_IS_WEAK
+@cindex S_IS_WEAK
+Return non-zero if the symbol is weak.
+
+@item S_IS_COMMON
+@cindex S_IS_COMMON
+Return non-zero if this is a common symbol.  Common symbols are sometimes
+represented as undefined symbols with a value, in which case this function will
+not be reliable.
+
+@item S_IS_DEFINED
+@cindex S_IS_DEFINED
+Return non-zero if this symbol is defined.  This function is not reliable when
+called on a common symbol.
+
+@item S_IS_DEBUG
+@cindex S_IS_DEBUG
+Return non-zero if this is a debugging symbol.
+
+@item S_IS_LOCAL
+@cindex S_IS_LOCAL
+Return non-zero if this is a local assembler symbol which should not be
+included in the final symbol table.  Note that this is not the opposite of
+@code{S_IS_EXTERNAL}.  The @samp{-L} assembler option affects the return value
+of this function.
+
+@item S_SET_EXTERNAL
+@cindex S_SET_EXTERNAL
+Mark the symbol as externally visible.
+
+@item S_CLEAR_EXTERNAL
+@cindex S_CLEAR_EXTERNAL
+Mark the symbol as not externally visible.
+
+@item S_SET_WEAK
+@cindex S_SET_WEAK
+Mark the symbol as weak.
+
+@item S_GET_TYPE
+@item S_GET_DESC
+@item S_GET_OTHER
+@cindex S_GET_TYPE
+@cindex S_GET_DESC
+@cindex S_GET_OTHER
+Get the @code{type}, @code{desc}, and @code{other} fields of the symbol.  These
+are only defined for object file formats for which they make sense (primarily
+a.out).
+
+@item S_SET_TYPE
+@item S_SET_DESC
+@item S_SET_OTHER
+@cindex S_SET_TYPE
+@cindex S_SET_DESC
+@cindex S_SET_OTHER
+Set the @code{type}, @code{desc}, and @code{other} fields of the symbol.  These
+are only defined for object file formats for which they make sense (primarily
+a.out).
+
+@item S_GET_SIZE
+@cindex S_GET_SIZE
+Get the size of a symbol.  This is only defined for object file formats for
+which it makes sense (primarily ELF).
+
+@item S_SET_SIZE
+@cindex S_SET_SIZE
+Set the size of a symbol.  This is only defined for object file formats for
+which it makes sense (primarily ELF).
+@end table
+
+@node Expressions
 @subsection Expressions
 @cindex internals, expressions
 @cindex expressions, internal
-
-Expressions are stored as a combination of operator, symbols, blah.
-
+@cindex expressionS structure
+
+Expressions are stored in an @code{expressionS} structure.  The structure is
+defined in @file{expr.h}.
+
+@cindex expression
+The macro @code{expression} will create an @code{expressionS} structure based
+on the text found at the global variable @code{input_line_pointer}.
+
+@cindex make_expr_symbol
+@cindex expr_symbol_where
+A single @code{expressionS} structure can represent a single operation.
+Complex expressions are formed by creating @dfn{expression symbols} and
+combining them in @code{expressionS} structures.  An expression symbol is
+created by calling @code{make_expr_symbol}.  An expression symbol should
+naturally never appear in a symbol table, and the implementation of
+@code{S_IS_LOCAL} (@pxref{Symbols}) reflects that.  The function
+@code{expr_symbol_where} returns non-zero if a symbol is an expression symbol,
+and also returns the file and line for the expression which caused it to be
+created.
+
+The @code{expressionS} structure has two symbol fields, a number field, an
+operator field, and a field indicating whether the number is unsigned.
+
+The operator field is of type @code{operatorT}, and describes how to interpret
+the other fields; see the definition in @file{expr.h} for the possibilities.
+
+An @code{operatorT} value of @code{O_big} indicates either a floating point
+number, stored in the global variable @code{generic_floating_point_number}, or
+an integer to large to store in an @code{offsetT} type, stored in the global
+array @code{generic_bignum}.  This rather inflexible approach makes it
+impossible to use floating point numbers or large expressions in complex
+expressions.
+
+@node Fixups
 @subsection Fixups
 @cindex internals, fixups
 @cindex fixups
+@cindex fixS structure
+
+A @dfn{fixup} is basically anything which can not be resolved in the first
+pass.  Sometimes a fixup can be resolved by the end of the assembly; if not,
+the fixup becomes a relocation entry in the object file.
+
+@cindex fix_new
+@cindex fix_new_exp
+A fixup is created by a call to @code{fix_new} or @code{fix_new_exp}.  Both
+take a frag (@pxref{Frags}), a position within the frag, a size, an indication
+of whether the fixup is PC relative, and a type.  In a @code{BFD_ASSEMBLER}
+GAS, the type is nominally a @code{bfd_reloc_code_real_type}, but several
+targets use other type codes to represent fixups that can not be described as
+relocations.
+
+The @code{fixS} structure has a number of fields, several of which are obsolete
+or are only used by a particular target.  The important fields are:
+
+@table @code
+@item fx_frag
+The frag (@pxref{Frags}) this fixup is in.
+
+@item fx_where
+The location within the frag where the fixup occurs.
+
+@item fx_addsy
+The symbol this fixup is against.  Typically, the value of this symbol is added
+into the object contents.  This may be NULL.
+
+@item fx_subsy
+The value of this symbol is subtracted from the object contents.  This is
+normally NULL.
+
+@item fx_offset
+A number which is added into the fixup.
+
+@item fx_addnumber
+Some CPU backends use this field to convey information between
+@code{md_apply_fix} and @code{tc_gen_reloc}.  The machine independent code does
+not use it.
 
+@item fx_next
+The next fixup in the section.
+
+@item fx_r_type
+The type of the fixup.  This field is only defined if @code{BFD_ASSEMBLER}, or
+if the target defines @code{NEED_FX_R_TYPE}.
+
+@item fx_size
+The size of the fixup.  This is mostly used for error checking.
+
+@item fx_pcrel
+Whether the fixup is PC relative.
+
+@item fx_done
+Non-zero if the fixup has been applied, and no relocation entry needs to be
+generated.
+
+@item fx_file
+@itemx fx_line
+The file and line where the fixup was created.
+
+@item tc_fix_data
+This has the type @code{TC_FIX_TYPE}, and is only defined if the target defines
+that macro.
+@end table
+
+@node Frags
 @subsection Frags
 @cindex internals, frags
 @cindex frags
+@cindex fragS structure.
 
-The frag is the basic unit for storing section contents.
+The @code{fragS} structure is defined in @file{as.h}.  Each frag represents a
+portion of the final object file.  As GAS reads the source file, it creates
+frags to hold the data that it reads.  At the end of the assembly the frags and
+fixups are processed to produce the final contents.
 
 @table @code
-
 @item fr_address
 The address of the frag.  This is not set until the assembler rescans the list
 of all frags after the entire input file is parsed.  The function
@@ -145,15 +441,13 @@ be zero.
 Variable number of characters we may output, after the initial @code{fr_fix}
 characters.  May be zero.
 
-@item fr_symbol
-@itemx fr_offset
-Foo.
-
-@item fr_opcode
-Points to the lowest-addressed byte of the opcode, for use in relaxation.
+@item fr_offset
+The interpretation of this field is controlled by @code{fr_type}.  Generally,
+if @code{fr_var} is non-zero, this is a repeat count: the @code{fr_var}
+characters are output @code{fr_offset} times.
 
 @item line
-Holds line-number info.
+Holds line number info when an assembler listing was requested.
 
 @item fr_type
 Relaxation state.  This field indicates the interpretation of @code{fr_offset},
@@ -164,18 +458,16 @@ verbatim (fixups aside).  See below for specific values this field can have.
 
 @item fr_subtype
 Relaxation substate.  If the macro @code{md_relax_frag} isn't defined, this is
-assumed to be an index into @code{md_relax_table} for the generic relaxation
-code to process.  (@xref{Relaxation}.)  If @code{md_relax_frag} is defined,
-this field is available for any use by the CPU-specific code.
-
-@item align_mask
-@itemx align_offset
-These fields are not used yet.  They are intended to keep track of the
-alignment of the current frag within its section, even if the exact offset
-isn't known.  In many cases, we should be able to avoid creating extra frags
-when @code{.align} directives are given; instead, the number of bytes needed
-may be computable when the @code{.align} directive is processed.  Hmm.  Is this
-the right place for these, or should they be in the @code{frchainS} structure?
+assumed to be an index into @code{TC_GENERIC_RELAX_TABLE} for the generic
+relaxation code to process (@pxref{Relaxation}).  If @code{md_relax_frag} is
+defined, this field is available for any use by the CPU-specific code.
+
+@item fr_symbol
+This normally indicates the symbol to use when relaxing the frag according to
+@code{fr_type}.
+
+@item fr_opcode
+Points to the lowest-addressed byte of the opcode, for use in relaxation.
 
 @item fr_pcrel_adjust
 @itemx fr_bsr
@@ -183,10 +475,13 @@ These fields are only used in the NS32k configuration.  But since @code{struct
 frag} is defined before the CPU-specific header files are included, they must
 unconditionally be defined.
 
+@item fr_file
+@itemx fr_line
+The file and line where this frag was last modified.
+
 @item fr_literal
 Declared as a one-character array, this last field grows arbitrarily large to
 hold the actual contents of the frag.
-
 @end table
 
 These are the possible relaxation states, provided in the enumeration type
@@ -194,22 +489,24 @@ These are the possible relaxation states, provided in the enumeration type
 fields:
 
 @table @code
-
 @item rs_align
+@itemx rs_align_code
 The start of the following frag should be aligned on some boundary.  In this
 frag, @code{fr_offset} is the logarithm (base 2) of the alignment in bytes.
 (For example, if alignment on an 8-byte boundary were desired, @code{fr_offset}
 would have a value of 3.)  The variable characters indicate the fill pattern to
-be used.  (More than one?)
+be used.  Target backends can use @code{rs_align_code} to handle certain types
+of alignment differently.
 
 @item rs_broken_word
-This indicates that ``broken word'' processing should be done.  @xref{Broken
-Words,,Broken Words}.  If broken word processing is not necessary on the target
-machine, this enumerator value will not be defined.
+This indicates that ``broken word'' processing should be done (@pxref{Broken
+words}).  If broken word processing is not necessary on the target machine,
+this enumerator value will not be defined.
 
 @item rs_fill
 The variable characters are to be repeated @code{fr_offset} times.  If
-@code{fr_offset} is 0, this frag has a length of @code{fr_fix}.
+@code{fr_offset} is 0, this frag has a length of @code{fr_fix}.  Most frags
+have this type.
 
 @item rs_machine_dependent
 Displacement relaxation is to be done on this frag.  The target is indicated by
@@ -218,24 +515,23 @@ particular machine-specific addressing mode desired.  @xref{Relaxation}.
 
 @item rs_org
 The start of the following frag should be pushed back to some specific offset
-within the section.  (Some assemblers use the value as an absolute address; the
-@sc{gnu} assembler does not handle final absolute addresses, it requires that
-the linker set them.)  The offset is given by @code{fr_symbol} and
-@code{fr_offset}; one character from the variable-length tail is used as the
-fill character.
-
+within the section.  (Some assemblers use the value as an absolute address; GAS
+does not handle final absolute addresses, but rather requires that the linker
+set them.)  The offset is given by @code{fr_symbol} and @code{fr_offset}; one
+character from the variable-length tail is used as the fill character.
 @end table
 
+@cindex frchainS structure
 A chain of frags is built up for each subsection.  The data structure
 describing a chain is called a @code{frchainS}, and contains the following
 fields:
 
 @table @code
 @item frch_root
-Points to the first frag in the chain.  May be null if there are no frags in
+Points to the first frag in the chain.  May be NULL if there are no frags in
 this chain.
 @item frch_last
-Points to the last frag in the chain, or null if there are none.
+Points to the last frag in the chain, or NULL if there are none.
 @item frch_next
 Next in the list of @code{frchainS} structures.
 @item frch_seg
@@ -243,11 +539,13 @@ Indicates the section this frag chain belongs to.
 @item frch_subseg
 Subsection (subsegment) number of this frag chain.
 @item fix_root, fix_tail
-(Defined only if @code{BFD_ASSEMBLER} is defined.)  Point to first and last
+(Defined only if @code{BFD_ASSEMBLER} is defined).  Point to first and last
 @code{fixS} structures associated with this subsection.
 @item frch_obstack
 Not currently used.  Intended to be used for frag allocation for this
 subsection.  This should reduce frag generation caused by switching sections.
+@item frch_frag_now
+The current frag for this subsegment.
 @end table
 
 A @code{frchainS} corresponds to a subsection; each section has a list of
@@ -260,99 +558,657 @@ After the input files have been completely processed, and no more frags are to
 be generated, the frag chains are joined into one per section for further
 processing.  After this point, it is safe to operate on one chain per section.
 
-@node Broken Words
-@subsection Broken Words
-@cindex internals, broken words
-@cindex broken words
-@cindex promises, promises
-
-The ``broken word'' idea derives from the fact that some compilers, including
-@code{gcc}, will sometimes emit switch tables specifying 16-bit @code{.word}
-displacements to branch targets, and branch instructions that load entries from
-that table to compute the target address.  If this is done on a 32-bit machine,
-there is a chance (at least with really large functions) that the displacement
-will not fit in 16 bits.  Thus the ``broken word'' idea is well named, since
-there is an implied promise that the 16-bit field will in fact hold the
-specified displacement.
-
-If the ``broken word'' processing is enabled, and a situation like this is
-encountered, the assembler will insert a jump instruction into the instruction
-stream, close enough to be reached with the 16-bit displacement.  This jump
-instruction will transfer to the real desired target address.  Thus, as long as
-the @code{.word} value really is used as a displacement to compute an address
-to jump to, the net effect will be correct (minus a very small efficiency
-cost).  If @code{.word} directives with label differences for values are used
-for other purposes, however, things may not work properly.  I think there is a
-command-line option to turn on warnings when a broken word is discovered.
-
-This code is turned off by the @code{WORKING_DOT_WORD} macro.  It isn't needed
-if @code{.word} emits a value large enough to contain an address (or, more
-correctly, any possible difference between two addresses).
-
-@node What Happens?
-@section What Happens?
-
-Blah blah blah, initialization, argument parsing, file reading, whitespace
-munging, opcode parsing and lookup, operand parsing.  Now it's time to write
-the output file.
-
-In @code{BFD_ASSEMBLER} mode, processing of relocations and symbols and
-creation of the output file is initiated by calling @code{write_object_file}.
-
-@node Target Dependent Definitions
-@section Target Dependent Definitions
-
-@subsection Format-specific definitions
-
-@defmac obj_sec_sym_ok_for_reloc (section)
-(@code{BFD_ASSEMBLER} only.)
-Is it okay to use this section's section-symbol in a relocation entry?  If not,
-a new internal-linkage symbol is generated and emitted if such a relocation
-entry is needed.  (Default: Always use a new symbol.)
-
-@end defmac
-
-@defmac obj_adjust_symtab
-(@code{BFD_ASSEMBLER} only.)
-If this macro is defined, it is invoked just before setting the symbol table of
-the output BFD.  Any finalizing changes needed in the symbol table should be
-done here.  For example, in the COFF support, if there is no @code{.file}
-symbol defined already, one is generated at this point.  If no such adjustments
-are needed, this macro need not be defined.
-
-@end defmac
-
-@defmac EMIT_SECTION_SYMBOLS
-(@code{BFD_ASSEMBLER} only.)
-Should section symbols be included in the symbol list if they're used in
-relocations?  Some formats can generate section-relative relocations, and thus
-don't need symbols emitted for them.  (Default: 1.)
-@end defmac
-
-@defmac obj_frob_file
-Any final cleanup needed before writing out the BFD may be done here.  For
-example, ECOFF formats (and MIPS ELF format) may do some work on the MIPS-style
-symbol table with its integrated debug information.  The symbol table should
-not be modified at this time.
-@end defmac
-
-@subsection CPU-specific definitions
+The assembler always has a current frag, named @code{frag_now}.  More space is
+allocated for the current frag using the @code{frag_more} function; this
+returns a pointer to the amount of requested space.  Relaxing is done using
+variant frags allocated by @code{frag_var} or @code{frag_variant}
+(@pxref{Relaxation}).
+
+@node GAS processing
+@section What GAS does when it runs
+@cindex internals, overview
+
+This is a quick look at what an assembler run looks like.
+
+@itemize @bullet
+@item
+The assembler initializes itself by calling various init routines.
+
+@item
+For each source file, the @code{read_a_source_file} function reads in the file
+and parses it.  The global variable @code{input_line_pointer} points to the
+current text; it is guaranteed to be correct up to the end of the line, but not
+farther.
+
+@item
+For each line, the assembler passes labels to the @code{colon} function, and
+isolates the first word.  If it looks like a pseudo-op, the word is looked up
+in the pseudo-op hash table @code{po_hash} and dispatched to a pseudo-op
+routine.  Otherwise, the target dependent @code{md_assemble} routine is called
+to parse the instruction.
+
+@item
+When pseudo-ops or instructions output data, they add it to a frag, calling
+@code{frag_more} to get space to store it in.
+
+@item
+Pseudo-ops and instructions can also output fixups created by @code{fix_new} or
+@code{fix_new_exp}.
+
+@item
+For certain targets, instructions can create variant frags which are used to
+store relaxation information (@pxref{Relaxation}).
+
+@item
+When the input file is finished, the @code{write_object_file} routine is
+called.  It assigns addresses to all the frags (@code{relax_segment}), resolves
+all the fixups (@code{fixup_segment}), resolves all the symbol values (using
+@code{resolve_symbol_value}), and finally writes out the file (in the
+@code{BFD_ASSEMBLER} case, this is done by simply calling @code{bfd_close}).
+@end itemize
+
+@node Porting GAS
+@section Porting GAS
+@cindex porting
+
+Each GAS target specifies two main things: the CPU file and the object format
+file.  Two main switches in the @file{configure.in} file handle this.  The
+first switches on CPU type to set the shell variable @code{cpu_type}.  The
+second switches on the entire target to set the shell variable @code{fmt}.
+
+The configure script uses the value of @code{cpu_type} to select two files in
+the @file{config} directory: @file{tc-@var{CPU}.c} and @file{tc-@var{CPU}.h}.
+The configuration process will create symlinks to these files from
+@file{targ-cpu.c} and @file{targ-cpu.h} in the build directory.
+
+The configure script also uses the value of @code{fmt} to select two files:
+@file{obj-@var{fmt}.c} and @file{obj-@var{fmt}.h}.  The configuration process
+will create symlinks to these files from @file{obj-format.h} and
+@file{obj-format.c}.
+
+You can also set the emulation in the configure script by setting the @code{em}
+variable.  Normally the default value of @samp{generic} is fine.  The
+configuration process will create a symlink from @file{targ-env.h} to
+@file{te-@var{em}.h}.
+
+Porting GAS to a new CPU requires writing the @file{tc-@var{CPU}} files.
+Porting GAS to a new object file format requires writing the
+@file{obj-@var{fmt}} files.  There is sometimes some interaction between these
+two files, but it is normally minimal.
+
+The best approach is, of course, to copy existing files.  The documentation
+below assumes that you are looking at existing files to see usage details.
+
+These interfaces have grown over time, and have never been carefully thought
+out or designed.  Nothing about the interfaces described here is cast in stone.
+It is possible that they will change from one version of the assembler to the
+next.  Also, new macros are added all the time as they are needed.
+
+@menu
+* CPU backend::                 Writing a CPU backend
+* Object format backend::       Writing an object format backend
+* Emulations::                  Writing emulation files
+@end menu
+
+@node CPU backend
+@subsection Writing a CPU backend
+@cindex CPU backend
+@cindex @file{tc-@var{CPU}}
+
+The CPU backend files are the heart of the assembler.  They are the only parts
+of the assembler which actually know anything about the instruction set of the
+processor.
+
+You must define a reasonably small list of macros and functions in the CPU
+backend files.  You may define a large number of additional macros in the CPU
+backend files, not all of which are documented here.  You must, of course,
+define macros in the @file{.h} file, which is included by every assembler
+source file.  You may define the functions as macros in the @file{.h} file, or
+as functions in the @file{.c} file.
+
+@table @code
+@item TC_@var{CPU}
+@cindex TC_@var{CPU}
+By convention, you should define this macro in the @file{.h} file.  For
+example, @file{tc-m68k.h} defines @code{TC_M68K}.  You might have to use this
+if it is necessary to add CPU specific code to the object format file.
+
+@item TARGET_FORMAT
+This macro is the BFD target name to use when creating the output file.  This
+will normally depend upon the @code{OBJ_@var{FMT}} macro.
+
+@item TARGET_ARCH
+This macro is the BFD architecture to pass to @code{bfd_set_arch_mach}.
+
+@item TARGET_MACH
+This macro is the BFD machine number to pass to @code{bfd_set_arch_mach}.  If
+it is not defined, GAS will use 0.
+
+@item TARGET_BYTES_BIG_ENDIAN
+You should define this macro to be non-zero if the target is big endian, and
+zero if the target is little endian.
+
+@item md_shortopts
+@itemx md_longopts
+@itemx md_longopts_size
+@itemx md_parse_option
+@itemx md_show_usage
+@cindex md_shortopts
+@cindex md_longopts
+@cindex md_longopts_size
+@cindex md_parse_option
+@cindex md_show_usage
+GAS uses these variables and functions during option processing.
+@code{md_shortopts} is a @code{const char *} which GAS adds to the machine
+independent string passed to @code{getopt}.  @code{md_longopts} is a
+@code{struct option []} which GAS adds to the machine independent long options
+passed to @code{getopt}; you may use @code{OPTION_MD_BASE}, defined in
+@file{as.h}, as the start of a set of long option indices, if necessary.
+@code{md_longopts_size} is a @code{size_t} holding the size @code{md_longopts}.
+GAS will call @code{md_parse_option} whenever @code{getopt} returns an
+unrecognized code, presumably indicating a special code value which appears in
+@code{md_longopts}.  GAS will call @code{md_show_usage} when a usage message is
+printed; it should print a description of the machine specific options.
+
+@item md_begin
+@cindex md_begin
+GAS will call this function at the start of the assembly, after the command
+line arguments have been parsed and all the machine independent initializations
+have been completed.
+
+@item md_cleanup
+@cindex md_cleanup
+If you define this macro, GAS will call it at the end of each input file.
+
+@item md_assemble
+@cindex md_assemble
+GAS will call this function for each input line which does not contain a
+pseudo-op.  The argument is a null terminated string.  The function should
+assemble the string as an instruction with operands.  Normally
+@code{md_assemble} will do this by calling @code{frag_more} and writing out
+some bytes (@pxref{Frags}).  @code{md_assemble} will call @code{fix_new} to
+create fixups as needed (@pxref{Fixups}).  Targets which need to do special
+purpose relaxation will call @code{frag_var}.
+
+@item md_pseudo_table
+@cindex md_pseudo_table
+This is a const array of type @code{pseudo_typeS}.  It is a mapping from
+pseudo-op names to functions.  You should use this table to implement
+pseudo-ops which are specific to the CPU.
+
+@item tc_conditional_pseudoop
+@cindex tc_conditional_pseudoop
+If this macro is defined, GAS will call it with a @code{pseudo_typeS} argument.
+It should return non-zero if the pseudo-op is a conditional which controls
+whether code is assembled, such as @samp{.if}.  GAS knows about the normal
+conditional pseudo-ops,and you should normally not have to define this macro.
+
+@item comment_chars
+@cindex comment_chars
+This is a null terminated @code{const char} array of characters which start a
+comment.
+
+@item tc_comment_chars
+@cindex tc_comment_chars
+If this macro is defined, GAS will use it instead of @code{comment_chars}.
+
+@item line_comment_chars
+@cindex line_comment_chars
+This is a null terminated @code{const char} array of characters which start a
+comment when they appear at the start of a line.
+
+@item line_separator_chars
+@cindex line_separator_chars
+This is a null terminated @code{const char} array of characters which separate
+lines (the semicolon is such a character by default, and need not be listed in
+this array).
+
+@item EXP_CHARS
+@cindex EXP_CHARS
+This is a null terminated @code{const char} array of characters which may be
+used as the exponent character in a floating point number.  This is normally
+@code{"eE"}.
+
+@item FLT_CHARS
+@cindex FLT_CHARS
+This is a null terminated @code{const char} array of characters which may be
+used to indicate a floating point constant.  A zero followed by one of these
+characters is assumed to be followed by a floating point number; thus they
+operate the way that @code{0x} is used to indicate a hexadecimal constant.
+Usually this includes @samp{r} and @samp{f}.
+
+@item LEX_AT
+@cindex LEX_AT
+You may define this macro to the lexical type of the @kbd{@}} character.  The
+default is zero.
+
+Lexical types are a combination of @code{LEX_NAME} and @code{LEX_BEGIN_NAME},
+both defined in @file{read.h}.  @code{LEX_NAME} indicates that the character
+may appear in a name.  @code{LEX_BEGIN_NAME} indicates that the character may
+appear at the beginning of a nem.
+
+@item LEX_BR
+@cindex LEX_BR
+You may define this macro to the lexical type of the brace characters @kbd{@{},
+@kbd{@}}, @kbd{[}, and @kbd{]}.  The default value is zero.
+
+@item LEX_PCT
+@cindex LEX_PCT
+You may define this macro to the lexical type of the @kbd{%} character.  The
+default value is zero.
+
+@item LEX_QM
+@cindex LEX_QM
+You may define this macro to the lexical type of the @kbd{?} character.  The
+default value it zero.
+
+@item LEX_DOLLAR
+@cindex LEX_DOLLAR
+You may define this macro to the lexical type of the @kbd{$} character.  The
+default value is @code{LEX_NAME | LEX_BEGIN_NAME}.
+
+@item SINGLE_QUOTE_STRINGS
+@cindex SINGLE_QUOTE_STRINGS
+If you define this macro, GAS will treat single quotes as string delimiters.
+Normally only double quotes are accepted as string delimiters.
+
+@item NO_STRING_ESCAPES
+@cindex NO_STRING_ESCAPES
+If you define this macro, GAS will not permit escape sequences in a string.
+
+@item ONLY_STANDARD_ESCAPES
+@cindex ONLY_STANDARD_ESCAPES
+If you define this macro, GAS will warn about the use of nonstandard escape
+sequences in a string.
+
+@item md_start_line_hook
+@cindex md_start_line_hook
+If you define this macro, GAS will call it at the start of each line.
+
+@item LABELS_WITHOUT_COLONS
+@cindex LABELS_WITHOUT_COLONS
+If you define this macro, GAS will assume that any text at the start of a line
+is a label, even if it does not have a colon.
+
+@item TC_START_LABEL
+@cindex TC_START_LABEL
+You may define this macro to control what GAS considers to be a label.  The
+default definition is to accept any name followed by a colon character.
+
+@item NO_PSEUDO_DOT
+@cindex NO_PSEUDO_DOT
+If you define this macro, GAS will not require pseudo-ops to start with a
+@kbd{.} character.
+
+@item TC_EQUAL_IN_INSN
+@cindex TC_EQUAL_IN_INSN
+If you define this macro, it should return nonzero if the instruction is
+permitted to contain an @kbd{=} character.  GAS will use this to decide if a
+@kbd{=} is an assignment or an instruction.
+
+@item TC_EOL_IN_INSN
+@cindex TC_EOL_IN_INSN
+If you define this macro, it should return nonzero if the current input line
+pointer should be treated as the end of a line.
+
+@item md_parse_name
+@cindex md_parse_name
+If this macro is defined, GAS will call it for any symbol found in an
+expression.  You can define this to handle special symbols in a special way.
+If a symbol always has a certain value, you should normally enter it in the
+symbol table, perhaps using @code{reg_section}.
+
+@item md_operand
+@cindex md_operand
+GAS will call this function for any expression that can not be recognized.
+When the function is called, @code{input_line_pointer} will point to the start
+of the expression.
+
+@item tc_unrecognized_line
+@cindex tc_unrecognized_line
+If you define this macro, GAS will call it when it finds a line that it can not
+parse.
+
+@item md_do_align
+@cindex md_do_align
+You may define this macro to handle an alignment directive.  GAS will call it
+when the directive is seen in the input file.  For example, the i386 backend
+uses this to generate efficient nop instructions of varying lengths, depending
+upon the number of bytes that the alignment will skip.
+
+@item HANDLE_ALIGN
+@cindex HANDLE_ALIGN
+You may define this macro to do special handling for an alignment directive.
+GAS will call it at the end of the assembly.
+
+@item md_flush_pending_output
+@cindex md_flush_pending_output
+If you define this macro, GAS will it each time it skips any space because of a
+space filling or alignment or data allocation pseudo-op.
+
+@item TC_PARSE_CONS_EXPRESSION
+@cindex TC_PARSE_CONS_EXPRESSION
+You may define this macro to parse an expression used in a data allocation
+pseudo-op such as @code{.word}.  You can use this to recognize relocation
+directives that may appear in such directives.
+
+@item BITFIELD_CONS_EXPRESSION
+@cindex BITFIELD_CONS_EXPRESSION
+If you define this macro, GAS will recognize bitfield instructions in data
+allocation pseudo-ops, as used on the i960.
+
+@item REPEAT_CONS_EXPRESSION
+@cindex REPEAT_CONS_EXPRESSION
+If you define this macro, GAS will recognize repeat counts in data allocation
+pseudo-ops, as used on the MIPS.
+
+@item md_cons_align
+@cindex md_cons_align
+You may define this macro to do any special alignment before a data allocation
+pseudo-op.
+
+@item TC_CONS_FIX_NEW
+@cindex TC_CONS_FIX_NEW
+You may define this macro to generate a fixup for a data allocation pseudo-op.
+
+@item md_number_to_chars
+@cindex md_number_to_chars
+This should just call either @code{number_to_chars_bigendian} or
+@code{number_to_chars_littleendian}, whichever is appropriate.  On targets like
+the MIPS which support options to change the endianness, which function to call
+is a runtime decision.  On other targets, @code{md_number_to_chars} can be a
+simple macro.
+
+@item md_reloc_size
+@cindex md_reloc_size
+This variable is only used in the original version of gas (not
+@code{BFD_ASSEMBLER} and not @code{MANY_SEGMENTS}).  It holds the size of a
+relocation entry.
+
+@item WORKING_DOT_WORD
+@itemx md_short_jump_size
+@itemx md_long_jump_size
+@itemx md_create_short_jump
+@itemx md_create_long_jump
+@cindex WORKING_DOT_WORD
+@cindex md_short_jump_size
+@cindex md_long_jump_size
+@cindex md_create_short_jump
+@cindex md_create_long_jump
+If @code{WORKING_DOT_WORD} is defined, GAS will not do broken word processing
+(@pxref{Broken words}).  Otherwise, you should set @code{md_short_jump_size} to
+the size of a short jump (a jump that is just long enough to jump around a long
+jmp) and @code{md_long_jump_size} to the size of a long jump (a jump that can
+go anywhere in the function), You should define @code{md_create_short_jump} to
+create a short jump around a long jump, and define @code{md_create_long_jump}
+to create a long jump.
+
+@item md_estimate_size_before_relax
+@cindex md_estimate_size_before_relax
+This function returns an estimate of the size of a @code{rs_machine_dependent}
+frag before any relaxing is done.  It may also create any necessary
+relocations.
+
+@item md_relax_frag
+@cindex md_relax_frag
+This macro may be defined to relax a frag.  GAS will call this with the frag
+and the change in size of all previous frags; @code{md_relax_frag} should
+return the change in size of the frag.  @xref{Relaxation}.
+
+@item TC_GENERIC_RELAX_TABLE
+@cindex TC_GENERIC_RELAX_TABLE
+If you do not define @code{md_relax_frag}, you may define
+@code{TC_GENERIC_RELAX_TABLE} as a table of @code{relax_typeS} structures.  The
+machine independent code knows how to use such a table to relax PC relative
+references.  See @file{tc-m68k.c} for an example.  @xref{Relaxation}.
+
+@item md_prepare_relax_scan
+@cindex md_prepare_relax_scan
+If defined, it is a C statement that is invoked prior to scanning
+the relax table.
+
+@item LINKER_RELAXING_SHRINKS_ONLY
+@cindex LINKER_RELAXING_SHRINKS_ONLY
+If you define this macro, and the global variable @samp{linkrelax} is set
+(because of a command line option, or unconditionally in @code{md_begin}), a
+@samp{.align} directive will cause extra space to be allocated.  The linker can
+then discard this space when relaxing the section.
+
+@item md_convert_frag
+@cindex md_convert_frag
+GAS will call this for each rs_machine_dependent fragment.
+The instruction is completed using the data from the relaxation pass.
+It may also create an necessary relocations.
+@xref{Relaxation}.
+
+@item md_apply_fix
+@cindex md_apply_fix
+GAS will call this for each fixup.  It should store the correct value in the
+object file.
+
+@item TC_HANDLES_FX_DONE
+@cindex TC_HANDLES_FX_DONE
+If this macro is defined, it means that @code{md_apply_fix} correctly sets the
+@code{fx_done} field in the fixup.
+
+@item tc_gen_reloc
+@cindex tc_gen_reloc
+A @code{BFD_ASSEMBLER} GAS will call this to generate a reloc.  GAS will pass
+the resulting reloc to @code{bfd_install_relocation}.  This currently works
+poorly, as @code{bfd_install_relocation} often does the wrong thing, and
+instances of @code{tc_gen_reloc} have been written to work around the problems,
+which in turns makes it difficult to fix @code{bfd_install_relocation}.
+
+@item RELOC_EXPANSION_POSSIBLE
+@cindex RELOC_EXPANSION_POSSIBLE
+If you define this macro, it means that @code{tc_gen_reloc} may return multiple
+relocation entries for a single fixup.  In this case, the return value of
+@code{tc_gen_reloc} is a pointer to a null terminated array.
+
+@item MAX_RELOC_EXPANSION
+@cindex MAX_RELOC_EXPANSION
+You must define this if @code{RELOC_EXPANSION_POSSIBLE} is defined; it
+indicates the largest number of relocs which @code{tc_gen_reloc} may return for
+a single fixup.
+
+@item tc_fix_adjustable
+@cindex tc_fix_adjustable
+You may define this macro to indicate whether a fixup against a locally defined
+symbol should be adjusted to be against the section symbol.  It should return a
+non-zero value if the adjustment is acceptable.
+
+@item MD_PCREL_FROM_SECTION
+@cindex MD_PCREL_FROM_SECTION
+If you define this macro, it should return the offset between the address of a
+PC relative fixup and the position from which the PC relative adjustment should
+be made.  On many processors, the base of a PC relative instruction is the next
+instruction, so this macro would return the length of an instruction.
+
+@item md_pcrel_from
+@cindex md_pcrel_from
+This is the default value of @code{MD_PCREL_FROM_SECTION}.  The difference is
+that @code{md_pcrel_from} does not take a section argument.
+
+@item tc_frob_label
+@cindex tc_frob_label
+If you define this macro, GAS will call it each time a label is defined.
+
+@item md_section_align
+@cindex md_section_align
+GAS will call this function for each section at the end of the assemebly, to
+permit the CPU backend to adjust the alignment of a section.
+
+@item tc_frob_section
+@cindex tc_frob_section
+If you define this macro, a @code{BFD_ASSEMBLER} GAS will call it for each
+section at the end of the assembly.
+
+@item tc_frob_file_before_adjust
+@cindex tc_frob_file_before_adjust
+If you define this macro, GAS will call it after the symbol values are
+resolved, but before the fixups have been changed from local symbols to section
+symbols.
+
+@item tc_frob_symbol
+@cindex tc_frob_symbol
+If you define this macro, GAS will call it for each symbol.  You can indicate
+that the symbol should not be included in the object file by definining this
+macro to set its second argument to a non-zero value.
+
+@item tc_frob_file
+@cindex tc_frob_file
+If you define this macro, GAS will call it after the symbol table has been
+completed, but before the relocations have been generated.
+
+@item tc_frob_file_after_relocs
+If you define this macro, GAS will call it after the relocs have been
+generated.
+@end table
+
+@node Object format backend
+@subsection Writing an object format backend
+@cindex object format backend
+@cindex @file{obj-@var{fmt}}
+
+As with the CPU backend, the object format backend must define a few things,
+and may define some other things.  The interface to the object format backend
+is generally simpler; most of the support for an object file format consists of
+defining a number of pseudo-ops.
+
+The object format @file{.h} file must include @file{targ-cpu.h}.
+
+This section will only define the @code{BFD_ASSEMBLER} version of GAS.  It is
+impossible to support a new object file format using any other version anyhow,
+as the original GAS version only supports a.out, and the @code{MANY_SEGMENTS}
+GAS version only supports COFF.
+
+@table @code
+@item OBJ_@var{format}
+@cindex OBJ_@var{format}
+By convention, you should define this macro in the @file{.h} file.  For
+example, @file{obj-elf.h} defines @code{OBJ_ELF}.  You might have to use this
+if it is necessary to add object file format specific code to the CPU file.
+
+@item obj_begin
+If you define this macro, GAS will call it at the start of the assembly, after
+the command line arguments have been parsed and all the machine independent
+initializations have been completed.
+
+@item obj_app_file
+@cindex obj_app_file
+If you define this macro, GAS will invoke it when it sees a @code{.file}
+pseudo-op or a @samp{#} line as used by the C preprocessor.
+
+@item OBJ_COPY_SYMBOL_ATTRIBUTES
+@cindex OBJ_COPY_SYMBOL_ATTRIBUTES
+You should define this macro to copy object format specific information from
+one symbol to another.  GAS will call it when one symbol is equated to
+another.
+
+@item obj_fix_adjustable
+@cindex obj_fix_adjustable
+You may define this macro to indicate whether a fixup against a locally defined
+symbol should be adjusted to be against the section symbol.  It should return a
+non-zero value if the adjustment is acceptable.
+
+@item obj_sec_sym_ok_for_reloc
+@cindex obj_sec_sym_ok_for_reloc
+You may define this macro to indicate that it is OK to use a section symbol in
+a relocateion entry.  If it is not, GAS will define a new symbol at the start
+of a section.
+
+@item EMIT_SECTION_SYMBOLS
+@cindex EMIT_SECTION_SYMBOLS
+You should define this macro with a zero value if you do not want to include
+section symbols in the output symbol table.  The default value for this macro
+is one.
+
+@item obj_adjust_symtab
+@cindex obj_adjust_symtab
+If you define this macro, GAS will invoke it just before setting the symbol
+table of the output BFD.  For example, the COFF support uses this macro to
+generate a @code{.file} symbol if none was generated previously.
+
+@item SEPARATE_STAB_SECTIONS
+@cindex SEPARATE_STAB_SECTIONS
+You may define this macro to indicate that stabs should be placed in separate
+sections, as in ELF.
+
+@item INIT_STAB_SECTION
+@cindex INIT_STAB_SECTION
+You may define this macro to initialize the stabs section in the output file.
+
+@item OBJ_PROCESS_STAB
+@cindex OBJ_PROCESS_STAB
+You may define this macro to do specific processing on a stabs entry.
+
+@item obj_frob_section
+@cindex obj_frob_section
+If you define this macro, GAS will call it for each section at the end of the
+assembly.
+
+@item obj_frob_file_before_adjust
+@cindex obj_frob_file_before_adjust
+If you define this macro, GAS will call it after the symbol values are
+resolved, but before the fixups have been changed from local symbols to section
+symbols.
+
+@item obj_frob_symbol
+@cindex obj_frob_symbol
+If you define this macro, GAS will call it for each symbol.  You can indicate
+that the symbol should not be included in the object file by definining this
+macro to set its second argument to a non-zero value.
+
+@item obj_frob_file
+@cindex obj_frob_file
+If you define this macro, GAS will call it after the symbol table has been
+completed, but before the relocations have been generated.
+
+@item obj_frob_file_after_relocs
+If you define this macro, GAS will call it after the relocs have been
+generated.
+@end table
+
+@node Emulations
+@subsection Writing emulation files
+
+Normally you do not have to write an emulation file.  You can just use
+@file{te-generic.h}.
+
+If you do write your own emulation file, it must include @file{obj-format.h}.
+
+An emulation file will often define @code{TE_@var{EM}}; this may then be used
+in other files to change the output.
 
 @node Relaxation
-@subsubsection Relaxation
-@cindex Relaxation
-
-If @code{md_relax_frag} isn't defined, the assembler will perform some
-relaxation on @code{rs_machine_dependent} frags based on the frag subtype and
-the displacement to some specified target address.  The basic idea is that many
-machines have different addressing modes for instructions that can specify
-different ranges of values, with successive modes able to access wider ranges,
-including the entirety of the previous range.  Smaller ranges are assumed to be
-more desirable (perhaps the instruction requires one word instead of two or
-three); if this is not the case, don't describe the smaller-range, inferior
-mode.
-
-The @code{fr_subtype} and the field of a frag is an index into a CPU-specific
+@section Relaxation
+@cindex relaxation
+
+@dfn{Relaxation} is a generic term used when the size of some instruction or
+data depends upon the value of some symbol or other data.
+
+GAS knows to relax a particular type of PC relative relocation using a table.
+You can also define arbitrarily complex forms of relaxation yourself.
+
+@menu
+* Relaxing with a table::       Relaxing with a table
+* General relaxing::            General relaxing
+@end menu
+
+@node Relaxing with a table
+@subsection Relaxing with a table
+
+If you do not define @code{md_relax_frag}, and you do define
+@code{TC_GENERIC_RELAX_TABLE}, GAS will relax @code{rs_machine_dependent} frags
+based on the frag subtype and the displacement to some specified target
+address.  The basic idea is that several machines have different addressing
+modes for instructions that can specify different ranges of values, with
+successive modes able to access wider ranges, including the entirety of the
+previous range.  Smaller ranges are assumed to be more desirable (perhaps the
+instruction requires one word instead of two or three); if this is not the
+case, don't describe the smaller-range, inferior mode.
+
+The @code{fr_subtype} field of a frag is an index into a CPU-specific
 relaxation table.  That table entry indicates the range of values that can be
 stored, the number of bytes that will have to be added to the frag to
 accomodate the addressing mode, and the index of the next entry to examine if
@@ -366,24 +1222,34 @@ compute an adjustment to be made to the displacement.
 
 The value fitted by the relaxation code is always assumed to be a displacement
 from the current frag.  (More specifically, from @code{fr_fix} bytes into the
-frag.)  This seems kinda silly.  What about fitting small absolute values?  I
-suppose @code{md_assemble} is supposed to take care of that, but if the operand
-is a difference between symbols, it might not be able to, if the difference was
-not computable yet.
+frag.)
+@ignore
+This seems kinda silly.  What about fitting small absolute values?  I suppose
+@code{md_assemble} is supposed to take care of that, but if the operand is a
+difference between symbols, it might not be able to, if the difference was not
+computable yet.
+@end ignore
 
 The end of the relaxation sequence is indicated by a ``next'' value of 0.  This
-is kinda silly too, since it means that the first entry in the table can't be
-used.  I think -1 would make a more logical sentinel value.
-
-The table @code{md_relax_table} from @file{targ-cpu.c} describes the relaxation
-modes available.  Currently this must always be provided, even on machines for
-which this type of relaxation isn't possible or practical.  Probably fewer than
-half the machines gas supports used it; it ought to be made conditional on some
-CPU-specific macro.  Currently, also that table must be declared ``const;'' on
-some machines, though, it might make sense to keep it writeable, so it can be
-modified depending on which CPU of a family is specified.  For example, in the
-m68k family, the 68020 has some addressing modes that are not available on the
-68000.
+means that the first entry in the table can't be used.
+
+For some configurations, the linker can do relaxing within a section of an
+object file.  If call instructions of various sizes exist, the linker can
+determine which should be used in each instance, when a symbol's value is
+resolved.  In order for the linker to avoid wasting space and having to insert
+no-op instructions, it must be able to expand or shrink the section contents
+while still preserving intra-section references and meeting alignment
+requirements.
+
+For the i960 using b.out format, no expansion is done; instead, each
+@samp{.align} directive causes extra space to be allocated, enough that when
+the linker is relaxing a section and removing unneeded space, it can discard
+some or all of this extra padding and cause the following data to be correctly
+aligned.
+
+For the H8/300, I think the linker expands calls that can't reach, and doesn't
+worry about alignment issues; the cpu probably never needs any significant
+alignment beyond the instruction size.
 
 The relaxation table type contains these fields:
 
@@ -395,8 +1261,7 @@ Backward reach, must be zero or negative.
 @item rlx_length
 Length in bytes of this addressing mode.
 @item rlx_more
-Index of the next-longer relax state, or zero if there is no ``next''
-relax state.
+Index of the next-longer relax state, or zero if there is no next relax state.
 @end table
 
 The relaxation is done in @code{relax_segment} in @file{write.c}.  The
@@ -413,16 +1278,11 @@ by the appropriate size, and fill in the appropriate bytes of the frag.
 frag_var as the second argument.)
 
 If relocation records are needed, they should be emitted by
-@code{md_estimate_size_before_relax}.
-
-These are the machine-specific definitions associated with the relaxation
-mechanism:
-
-@deftypefun int md_estimate_size_before_relax (fragS *@var{frag}, segT @var{sec})
-This function should examine the target symbol of the supplied frag and correct
-the @code{fr_subtype} of the frag if needed.  When this function is called, if
-the symbol has not yet been defined, it will not become defined later; however,
-its value may still change if the section it is in gets relaxed.
+@code{md_estimate_size_before_relax}.  This function should examine the target
+symbol of the supplied frag and correct the @code{fr_subtype} of the frag if
+needed.  When this function is called, if the symbol has not yet been defined,
+it will not become defined later; however, its value may still change if the
+section it is in gets relaxed.
 
 Usually, if the symbol is in the same section as the frag (given by the
 @var{sec} argument), the narrowest likely relaxation mode is stored in
@@ -441,215 +1301,88 @@ Sometimes @code{fr_var} is increased instead, and @code{frag_wane} is not
 called.  I'm not sure, but I think this is to keep @code{fr_fix} referring to
 an earlier byte, and @code{fr_subtype} set to @code{rs_machine_dependent} so
 that @code{md_convert_frag} will get called.
-@end deftypefun
-
-@deftypevar relax_typeS md_relax_table []
-This is the table.
-@end deftypevar
-
-@defmac md_relax_frag (@var{frag})
-
-This macro, if defined, overrides all of the processing described above.  It's
-only defined for the MIPS target CPU, and there it doesn't do anything; it's
-used solely to disable the relaxing code and free up the @code{fr_subtype}
-field for use by the CPU-specific code.
-
-@end defmac
-
-@defmac tc_frob_file
-Like @code{obj_frob_file}, this macro handles miscellaneous last-minute
-cleanup.  Currently only used on PowerPC/POWER support, for setting up a
-@code{.debug} section.  This macro should not cause the symbol table to be
-modified.
-
-@end defmac
-
-@node Source File Summary
-@section Source File Summary
-
-@subsection File Format Descriptions
-
-@subheading a.out
-
-The @code{a.out} format is described by @file{obj-aout.*}.
-
-@subheading b.out
-
-The @code{b.out} format, described by @file{obj-bout.*}, is similar to
-@code{a.out} format, except for a few additional fields in the file header
-describing section alignment and address.
-
-@subheading COFF
-
-Originally, @file{obj-coff} was a purely non-BFD version, and
-@file{obj-coffbfd} was created to use BFD for low-level byte-swapping.  When
-the @code{BFD_ASSEMBLER} conversion started, the first COFF target to be
-converted was using @file{obj-coff}, and the two files had diverged somewhat,
-and I didn't feel like first converting the support of that target over to use
-the low-level BFD interface.
-
-So @file{obj-coff} got converted, and to simplify certain things,
-@file{obj-coffbfd} got ``merged'' in with a brute-force approach.
-Specifically, preprocessor conditionals testing for @code{BFD_ASSEMBLER}
-effectively split the @file{obj-coff} files into the two separate versions.  It
-isn't pretty.  They will be merged more thoroughly, and eventually only the
-higher-level interface will be used.
-
-@subheading ECOFF
-
-All ECOFF configurations use BFD for writing object files.
-
-@subheading ELF
-
-ELF is a fairly reasonable format, without many of the deficiencies the other
-object file formats have.  (It's got some of its own, but not as bad as the
-others.)  All ELF configurations use BFD for writing object files.
-
-@subheading EVAX
-
-This is the format used on VMS.  Yes, someone has actually written BFD support
-for it.  The code hasn't been integrated yet though.
-
-@subheading HP300?
-
-@subheading IEEE?
-
-@subheading SOM
-
-@subheading XCOFF
 
-The XCOFF configuration is based on the COFF cofiguration (using the
-higher-level BFD interface).  In fact, it uses the same files in the assembler.
+@node General relaxing
+@subsection General relaxing
 
-@subheading VMS
+If using a simple table is not suitable, you may implement arbitrarily complex
+relaxation semantics yourself.  For example, the MIPS backend uses this to emit
+different instruction sequences depending upon the size of the symbol being
+accessed.
 
-This is the old Vax VMS support.  It doesn't use BFD.
+When you assemble an instruction that may need relaxation, you should allocate
+a frag using @code{frag_var} or @code{frag_variant} with a type of
+@code{rs_machine_dependent}.  You should store some sort of information in the
+@code{fr_subtype} field so that you can figure out what to do with the frag
+later.
 
-@subsection Processor Descriptions
+When GAS reaches the end of the input file, it will look through the frags and
+work out their final sizes.
 
-Foo: a29k, alpha, h8300, h8500, hppa, i386, i860, i960, m68k, m88k, mips,
-ns32k, ppc, sh, sparc, tahoe, vax, z8k.
+GAS will first call @code{md_estimate_size_before_relax} on each
+@code{rs_machine_dependent} frag.  This function must return an estimated size
+for the frag.
 
-@node M68k
-@subsubsection M68k
+GAS will then loop over the frags, calling @code{md_relax_frag} on each
+@code{rs_machine_dependent} frag.  This function should return the change in
+size of the frag.  GAS will keep looping over the frags until none of the frags
+changes size.
 
-The operand syntax handling is atrocious.  There is no clear specification of
-the operand syntax.  I'm looking into using a Bison grammar to replace much of
-it.
-
-Operands on the 68k series processors can have two displacement values
-specified, plus a base register and a (possibly scaled) index register of which
-only some bits might be used.  Thus a single 68k operand requires up to two
-expressions, two register numbers, and size and scale factors.  The
-@code{struct m68k_op} type also includes a field indicating the mode of the
-operand, and an @code{error} field indicating a problem encountered while
-parsing the operand.
-
-An instruction on the 68k may have up to 6 operands, although most of them have
-to be simple register operands.  Up to 11 (16-bit) words may be required to
-express the instruction.
-
-A @code{struct m68k_exp} expression contains an @code{expressionS}, pointers to
-the first and last characters of the input that produced the expression, an
-indication of the section to which the expression belongs, and a size field.
-I'm not sure what the size field describes.
-
-@subsubheading M68k addressing modes
-
-Many instructions used the low six bits of the first instruction word to
-describe the location of the operand, or how to compute the location.  The six
-bits are typically split into three for a ``mode'' and three for a ``register''
-value.  The interpretation of these values is as follows:
-
-@example
-Mode    Register        Operand addressing mode
-0       Dn              data register
-1       An              address register
-2       An              indirect
-3       An              indirect, post-increment
-4       An              indirect, pre-decrement
-5       An              indirect with displacement
-6       An              indirect with optional displacement and index;
-                        may involve multiple indirections and two
-                        displacements
-7       0               16-bit address follows
-7       1               32-bit address follows
-7       2               PC indirect with displacement
-7       3               PC indirect with optional displacements and index
-7       4               immediate 16- or 32-bit
-7       5,6,7           Reserved
-@end example
-
-On the 68000 and 68010, support for modes 6 and 7.3 are incomplete; the
-displacement must fit in 8 bits, and no scaling or index suppression is
-permitted.
-
-@subsubheading M68k relaxation modes
-
-The relaxation modes used on the 68k are:
-
-@table @code
-@item ABRANCH
-Case @samp{g} except when @code{BCC68000} is applicable.
-@item FBRANCH
-Coprocessor branches.
-@item PCREL
-Mode 7.2 -- program counter indirect with 16-bit displacement.  This is
-available on all processors.  Widens to 32-bit absolute.  Used only if the
-original code used @code{ABSL} mode, and the CPU is not a 68000 or 68010.
-(Why?  Those processors support mode 7.2.)
-@item BCC68000
-A conditional branch instruction, on the 68000 or 68010.  These instructions
-support only 16-bit displacements on these processors.  If a larger
-displacement is needed, the condition is negated and turned into a short branch
-around a jump instruction to the specified target.  This jump will have an
-long absolute addressing mode.
-@item DBCC
-Like @code{BCC68000}, but for @code{dbCC} (decrement and branch on condition)
-instructions.
-@item PCLEA
-Not currently used??  Short form is mode 7.2 (program counter indirect, 16-bit
-displacement); long form is 7.3/0x0170 (program counter indirect, suppressed
-index register, 32-bit displacement).  Used in progressive-930331 for mode
-@code{AOFF} with a PC-relative addressing mode and a displacement that won't
-fit in 16 bits, or which is variable and is not specified to have a size other
-than long.
-@item PCINDEX
-Newly added.  PC indirect with index.  An 8-bit displacement is supported on
-the 68000 and 68010, wider displacements on later processors.
-
-Well, actually, I haven't added it yet.  I need to soon, though.  It fixes a
-bug reported by a customer.
-@end table
-
-@subsection ``Emulation'' Descriptions
-
-These are the @file{te-*.h} files.
+@node Broken words
+@section Broken words
+@cindex internals, broken words
+@cindex broken words
 
-@node Foo
-@section Foo
+Some compilers, including GCC, will sometimes emit switch tables specifying
+16-bit @code{.word} displacements to branch targets, and branch instructions
+that load entries from that table to compute the target address.  If this is
+done on a 32-bit machine, there is a chance (at least with really large
+functions) that the displacement will not fit in 16 bits.  The assembler
+handles this using a concept called @dfn{broken words}.  This idea is well
+named, since there is an implied promise that the 16-bit field will in fact
+hold the specified displacement.
+
+If broken word processing is enabled, and a situation like this is encountered,
+the assembler will insert a jump instruction into the instruction stream, close
+enough to be reached with the 16-bit displacement.  This jump instruction will
+transfer to the real desired target address.  Thus, as long as the @code{.word}
+value really is used as a displacement to compute an address to jump to, the
+net effect will be correct (minus a very small efficiency cost).  If
+@code{.word} directives with label differences for values are used for other
+purposes, however, things may not work properly.  For targets which use broken
+words, the @samp{-K} option will warn when a broken word is discovered.
+
+The broken word code is turned off by the @code{WORKING_DOT_WORD} macro.  It
+isn't needed if @code{.word} emits a value large enough to contain an address
+(or, more correctly, any possible difference between two addresses).
+
+@node Internal functions
+@section Internal functions
+
+This section describes basic internal functions used by GAS.
 
-@subsection Warning and Error Messages
+@menu
+* Warning and error messages::  Warning and error messages
+* Hash tables::                 Hash tables
+@end menu
 
-@deftypefun  int had_warnings (void)
-@deftypefunx int had_errors (void)
+@node Warning and error messages
+@subsection Warning and error messages
 
+@deftypefun  @{@} int had_warnings (void)
+@deftypefunx @{@} int had_errors (void)
 Returns non-zero if any warnings or errors, respectively, have been printed
 during this invocation.
-
 @end deftypefun
 
-@deftypefun void as_perror (const char *@var{gripe}, const char *@var{filename})
-
+@deftypefun @{@} void as_perror (const char *@var{gripe}, const char *@var{filename})
 Displays a BFD or system error, then clears the error status.
-
 @end deftypefun
 
-@deftypefun  void as_tsktsk (const char *@var{format}, ...)
-@deftypefunx void as_warn (const char *@var{format}, ...)
-@deftypefunx void as_bad (const char *@var{format}, ...)
-@deftypefunx void as_fatal (const char *@var{format}, ...)
-
+@deftypefun  @{@} void as_tsktsk (const char *@var{format}, ...)
+@deftypefunx @{@} void as_warn (const char *@var{format}, ...)
+@deftypefunx @{@} void as_bad (const char *@var{format}, ...)
+@deftypefunx @{@} void as_fatal (const char *@var{format}, ...)
 These functions display messages about something amiss with the input file, or
 internal problems in the assembler itself.  The current file name and line
 number are printed, followed by the supplied message, formatted using
@@ -658,33 +1391,54 @@ number are printed, followed by the supplied message, formatted using
 An error indicated by @code{as_bad} will result in a non-zero exit status when
 the assembler has finished.  Calling @code{as_fatal} will result in immediate
 termination of the assembler process.
-
 @end deftypefun
 
-@deftypefun  void as_warn_where (char *@var{file}, unsigned int @var{line}, const char *@var{format}, ...)
-@deftypefunx void as_bad_where (char *@var{file}, unsigned int @var{line}, const char *@var{format}, ...)
-
+@deftypefun @{@} void as_warn_where (char *@var{file}, unsigned int @var{line}, const char *@var{format}, ...)
+@deftypefunx @{@} void as_bad_where (char *@var{file}, unsigned int @var{line}, const char *@var{format}, ...)
 These variants permit specification of the file name and line number, and are
 used when problems are detected when reprocessing information saved away when
 processing some earlier part of the file.  For example, fixups are processed
 after all input has been read, but messages about fixups should refer to the
 original filename and line number that they are applicable to.
-
 @end deftypefun
 
-@deftypefun  void fprint_value (FILE *@var{file}, valueT @var{val})
-@deftypefunx void sprint_value (char *@var{buf}, valueT @var{val})
-
+@deftypefun @{@} void fprint_value (FILE *@var{file}, valueT @var{val})
+@deftypefunx @{@} void sprint_value (char *@var{buf}, valueT @var{val})
 These functions are helpful for converting a @code{valueT} value into printable
 format, in case it's wider than modes that @code{*printf} can handle.  If the
 type is narrow enough, a decimal number will be produced; otherwise, it will be
-in hexadecimal (FIXME: currently without `0x' prefix).  The value itself is not
-examined to make this determination.
+in hexadecimal.  The value itself is not examined to make this determination.
+@end deftypefun
+
+@node Hash tables
+@subsection Hash tables
+@cindex hash tables
 
+@deftypefun @{@} @{struct hash_control *@} hash_new (void)
+Creates the hash table control structure.
 @end deftypefun
 
-@node Writing a new target
-@section Writing a new target
+@deftypefun @{@} void hash_die (struct hash_control *)
+Destroy a hash table.
+@end deftypefun
+
+@deftypefun @{@} PTR hash_delete (struct hash_control *, const char *)
+Deletes entry from the hash table, returns the value it had.
+@end deftypefun
+
+@deftypefun @{@} PTR hash_replace (struct hash_control *, const char *, PTR)
+Updates the value for an entry already in the table, returning the old value.
+If no entry was found, just returns NULL.
+@end deftypefun
+
+@deftypefun @{@} @{const char *@} hash_insert (struct hash_control *, const char *, PTR)
+Inserting a value already in the table is an error.
+Returns an error message or NULL.
+@end deftypefun
+
+@deftypefun @{@} @{const char *@} hash_jam (struct hash_control *, const char *, PTR)
+Inserts if the value isn't already present, updates it if it is.
+@end deftypefun
 
 @node Test suite
 @section Test suite