PATCH: A bit of libgloss documentation

[Mark Mitchell <mark at codesourcery dot com>]

Here's a patch to libgloss porting.texi to explain a bit about adding
a new BSP to libgloss.  

OK to apply?  Or, what did I get wrong?

Also, a ping:

http://sources.redhat.com/ml/newlib/2006/msg00264.html

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Index: doc/porting.texi
===================================================================
RCS file: /home/cvs/Repository/newlib/libgloss/doc/porting.texi,v
retrieving revision 1.1.5.1
diff -c -5 -p -r1.1.5.1 porting.texi
*** doc/porting.texi	7 Jul 2005 21:13:23 -0000	1.1.5.1
--- doc/porting.texi	14 Apr 2006 19:11:29 -0000
*************** new library is called Libgloss, for Gnu 
*** 129,138 ****
--- 129,139 ----
  @menu
  * Supported targets::           What targets libgloss currently
                                  supports.
  * Building libgloss::           How to configure and built libgloss
                                  for a target.
+ * Board support::               How to add support for a new board.
  @end menu
  
  @node Supported targets, Building libgloss, Libgloss, Libgloss
  @subsection Supported Targets
  Currently libgloss is being used for the following targets:
*************** board also has support for loading the S
*** 229,239 ****
  native compiler on HP-UX. WinBond supplies a set of DOS programs that
  will allow the loading of files via a bidirectional parallel port. This
  has never been tested with the output of GNU SOM, as this manual is
  mostly for Unix based systems. 
  
! @node Building libgloss, , Supported targets, Libgloss
  @subsection Configuring and building libgloss.
  
  Libgloss uses an autoconf based script to configure. Autoconf scripts
  are portable shell scripts that are generated from a configure.in file.
  Configure input scripts are based themselves on m4. Most configure
--- 230,240 ----
  native compiler on HP-UX. WinBond supplies a set of DOS programs that
  will allow the loading of files via a bidirectional parallel port. This
  has never been tested with the output of GNU SOM, as this manual is
  mostly for Unix based systems. 
  
! @node Building libgloss, Board support, Supported targets, Libgloss
  @subsection Configuring and building libgloss.
  
  Libgloss uses an autoconf based script to configure. Autoconf scripts
  are portable shell scripts that are generated from a configure.in file.
  Configure input scripts are based themselves on m4. Most configure
*************** variable, and if it is set, the search p
*** 298,307 ****
--- 299,354 ----
  is done with an installed cross compiler, then none of this needs to be
  used. This is done so libgloss will build automatically with a fresh,
  and uninstalled object tree. It also makes it easier to debug the other
  tools using libgloss's test suites.
  
+ @node Board support, , Building libgloss, Libgloss
+ @subsection Adding Support for a New Board
+ 
+ This section explains how to add support for a new board to libgloss.
+ In order to add support for a board, you must already have developed a
+ toolchain for the target architecture.
+ 
+ All of the changes you will make will be in the subdirectory named
+ after the architecture used by your board.  For example, if you are
+ developing support for a new ColdFire board, you will modify files in
+ the @file{m68k} subdirectory, as that subdirectory contains support
+ for all 68K devices, including architecture variants like ColdFire.
+ 
+ In general, you will be adding three components: a @file{crt0.S} file
+ (@pxref{Crt0}), a linker script (@pxref{Linker Scripts}), and a
+ hardware support library.  Each should be prefixed with the name of
+ your board.  For example, if you ard adding support for a new Surf
+ board, then you will be adding the assembly @file{surf-crt0.S} (which
+ will be assembled into @file{surf-crt0.o}), the linker script
+ @file{surf.ld}, and other C and assembly files which will be combined
+ into the hardware support library @file{libsurf.a}.
+ 
+ You should modify @file{Makefile.in} to define new variables
+ corresponding to your board.  Although there is some variation between
+ architectures, the general convention is to use the following format:
+ 
+ @example
+ # The name of the crt0.o file.
+ SURF_CRT0    = surf-crt0.o
+ # The name of the linker script.
+ SURF_SCRIPTS = surf.ld
+ # The name of the hardware support library.
+ SURF_BSP     = libsurf.a
+ # The object files that make up the hardware support library.
+ SURF_OBJS    = surf-file1.o surf-file2.o 
+ # The name of the Makefile target to use for installation.
+ SURF_INSTALL = install-surf
+ @end example
+ 
+ Then, you should create the @code{$@{SURF_BSP@}} and
+ @code{$@{SURF_INSTALL@}} make targets.  Add @code{$@{SURF_CRT0@}} to
+ the dependencies for the @code{all} target and add
+ @code{$@{SURF_INSTALL@}} to the dependencies for the @code{install}
+ target.  Now, when libgloss is built and installed, support for your
+ BSP will be installed as well.
+ 
  @node GCC, Libraries, Libgloss, Top
  @chapter Porting GCC
  
  Porting GCC requires two things, neither of which has anything to do
  with GCC. If GCC already supports a processor type, then all the work in