Path: utzoo!mnetor!uunet!husc6!mit-eddie!EE.ECN.PURDUE.EDU!lewie
From: lewie@EE.ECN.PURDUE.EDU (Jeff Lewis)
Newsgroups: comp.lang.c++
Subject: Re:  COFFing
Message-ID: <8805052224.AA14725@ee.ecn.purdue.edu>
Date: 5 May 88 22:24:11 GMT
Sender: uucp@eddie.MIT.EDU
Lines: 77

Re:  making gas write COFF format .o's

[rms] I think this is not the right way to support GCC on sysV.  It would be
[rms] better to make sysV look more like a GNU system.
 
[rms] This involves two steps:

[rms] * Write a translator which will convert a library object module from
[rms] COFF to BSD format.  This isn't terribly hard because there is no
[rms] debuggin information.

It's not terribly hard but it unecessarily adds to system maintenance.

[rms] * Modify GNU ld to add a minimal amount of stuff to the front of a
[rms] BSD format file to make it executable by the kernel.  The symbol table
[rms] will remain in BSD format.  This should be very little change.

You'll find the COFF format header to be very similar to what you describe.
It contains a file header followed by an a.out header (similar, but not
exactly like the BSD one).  You might as well be writing the COFF header.

The only complaint I have with sticking to BSD format is that COFF is
a maturation of the standard a.out format.  For example, it's designed to
hold debugging info in a structured manner - BSD hacks it in by encoding
types into a symbol name.

[rms] * Modify GDB to read such files.  This should be very little change.

Fortunately, someone's already written a COFF reader for gdb so there's
no change needed.

[rms] Now you can replace all the software for compilation, etc., with the
[rms] GNU software.

I understand perfectly your desire to stick with what you already have,
but a) it's not that difficult to support COFF, and b) you'll probably
end up improving on the loader interface later - current BSD format won't
support you into the future - why not do it now?

As per my previous letter, I should elaborate on my sketchy thoughts:

Re: Method #6 (have gcc output generic symtab info)

    RMS didn't like this 'cause it would add complexity to gcc/gas
and would require *another* format for debugging info.
    I intended this for a system where you get the compiler *and* the
assembler - that way you only need to support one output format.
In reality, you're gonna want to support BSD.  Gcc currently doesn't
support COFF anyway, so you piggyback COFF onto this format.  This
generic format *would be* the gdb format, so you merely have to extend
this to cover all your bases.  All in all you end up with only two
debug formats to support.
    It wouldn't add complexity to gcc as per above.  It would add
complexity to gas, I can't argure with that.  I think it would
be worth it - and I am willing to write the code.  As a plug, I write
fairly maintainable code.

Re: Method #7 (bag the traditional compiler/assembler/loader cycle)

    I was very unclear on this one.  What I really envisioned was writing
out pseudo object files directly from the compiler.  This wouldn't be
any more difficult than the current technique: instead of formatting
text for output, you'd just stick opcodes and addresses into a compact,
fixed format structure - essentially just what an assembler might
construct as it was scanning the input text.  All I'm suggesting is
ripping out all the steps in the middle.  The compiler dumps this pseudo
object file, and the 'assembler'/linker (there'd be no need to keep
the steps separate) would just suck in the 'object' file and do
all the final relocating and instruction optimizing.  You could have
this linker generate relocatable output if you needed an object
file understandable by a standard loader - or just put it
all together and make executables.

    This is all just skylarkin' for now anyway - but I would like to
hear what other people think about it.

--Jeff Lewis (lewie@ee.ecn.purdue.edu, pur-ee!lewie)