freebsd-skq/gnu/usr.bin/as/README.coff

80 lines
3.1 KiB
Plaintext

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)