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)