The coff patches intend to do the following :

   . Generate coff files very compatible with vanilla linker.
   . Understands coff debug directives.

Here are the guidelines of the work I have done :

   . Encapsulate format dependent code in macros where it is possible.
   . Where not possible differenciate with #ifdef
   . try not to change the calling conventions of the existing functions. 
	I made one exception : symbol_new. I would be pleased to hear about
	a better solution. (symbols.c)
   . Extend the use of N_TYPE_seg seg_N_TYPE tables so that segments can
	be manipulated without using their format dependent name. (subsegs.c)
   . Write a function to parse the .def debug directives
   . Write two small peaces of code to handle the .ln directive.
   . In write.c try to move all the cross compilation specifics (md_..) to
     format dependent files.
   . Encapsulate the data structures using generic types, macros calls.
   . Added too much code to resolve the complexity of the symbol table
     generated. Most of the code deals with debug stuff.
   . Create another makefile, shorter, cleaner.
   . Create a config.gas shell script to mimic the gcc,gdb... configuration
	mechanism. This reduce the complexity of the makefile.
   . Isolate the format dependent code in two files 
	coff.c coff.h
	aout.c aout.h
	elf.c elf.h    [ Not yet ;-]
   . added a little stack management routine for coff in file stack.c
   . isolate os specific flags in m- files

If further development is planed on it is should solve the following problems :

   . Encapsulate DESC & OTHER tests in a macro call. I'm not aware
	of their exact semantics.
   . Clean up the seg_N_TYPE N_TYPE_seg naming scheme
   . Try to remove as much reference to segment dependent names as possible
   . Find a cleaner solution for symbol_new.
   . Report the modifications on vax, ns32k, sparc machine dependent files.
	To acheive this goal, search for \<N_, sy_, symbol_new and symbolS.
   . Allow an arbitrary number of segments (spare sections .ctor .dtor .bletch)
   . Find a way to extend the debug information without breaking sdb
     compatibility. Mainly intended for G++.
   . should it do something to generate shared libraries objects ?

I have tested this code on the following processor/os. gcc-1.37.1 was
   used for all the tests.

386	SCO unix ODT
	gcc-1.37.1, gas, emacs-18.55

386	Esix rev C
	gas-1.37/write.s

386	Ix 2.02
	gas, all the X11R4 mit clients

386	CTIX 3.2
	xsol (X11R4 solitary game), gas

68030	unisoft 1.3	
	the kernel (V.3.2) + tcp/ip extensions
	bash-1.05, bison-1.11, compress-4.0, cproto, shar-3.49, diff-1.14,
	dist-18.55, flex-2.3, gas-1.37, gcc-1.37.1, gdb-3.6, grep-1.5,
	kermit, make-3.58, makedep, patch, printf, makeinfo, g++-1.37.1,
	tar-1.08, texi2roff, uuencode, uutraf-1.2, libg++-1.37.2, groff-0.5

68020	sunos 3.5 (no, not coff, just to be sure that I didn't
			introduce errors)
	gcc-1.37.1, gas, emacs-18.55, gdb-3.6, bison-1.11, diff-1.14, 
	make-3.58, tar-1.08

68030   sunos 4.0.3 (idem)
	gas

I would be glad to hear about new experiences

	Loic  (loic@adesign.uucp or loic@afp.uucp)