🚀 go-pugleaf

In article <8910261603.AA05478@lurch.Stanford.EDU> tiemann@lurch.stanford.edu writes:
>
>The person to whom you are referring, Ron Guilmette, did manage to get
>something working, but his way of getting it working was equivalent to
>hacking stabs the way that GNU does, so COFF gets no extra there. 
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

The (only) notable advantage that COFF has over a.out is that COFF format
allows for the possibility of "extra" user-defined sections (i.e. above and
beyond the normal .text, .data, and .bss sections).  I can think of
a couple of zillion uses for this particular feature.  It allows you to
get the linker to amalgamate little chucks of stuff for several input
(object) files into single big chunks in the output (executable) files.
This can be damn useful, not only for shared-library initialization,
but also (as I have demonstrated) for construction & destruction of
global objects.

>On the other hand, COFF hard-wires its type representation system to a
>four-bit encoding, all of which just happen to be taken by C.  This
>lack of extensibility precludes its use as a representation for
>symbolic information of C++ programs, since it is impossible to
>represent things like virtual function, base classes, destructors,
>member functions, pointers to members, etc.

Absolutely true.  The debugging information in COFF is a disaster!!!
Due to the fixed fields and lack of expandability, the COFF debug
stuff cannot even handle full ANSI-C (which requires up to 12-levels
of "pointer-ness" for data types), let alone all of the "data type"
information required to support C++ (e.g. "reference-ness").

If only we could (a) add extra sections onto a.out, and (b) get all the
kernels to accept a.out for executable files, I could die a happy man.

// rfg