Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!EE.ECN.PURDUE.EDU!lewie
From: lewie@EE.ECN.PURDUE.EDU (Jeff Lewis)
Newsgroups: comp.lang.c++
Subject: COFFing
Message-ID: <8805051722.AA02477@ee.ecn.purdue.edu>
Date: 5 May 88 17:22:22 GMT
Sender: dmh@eddie.MIT.EDU
Lines: 66


    Steve Simmons sez:
    
    One of the "problems" with gcc/g++ and gas on some systems is the lack
    of support for coff.  I'm starting a look at hacking gas to output coff
    format files.  Anyone out there who has started this already or has
    advice/warnings, please drop me a note.
		
    Note that gdb/gdb+ would undoubtably gain new uses should anyone want
    to start a parallel project.

I already have a working gas that produces COFF format object files
(68000 version).  It's shortcoming is that it doesn't yet accept the
debugging directives.  I'm currently working on that.

There are several options that come to mind for doing this.

1. I could have gcc output COFF-style directives and be nice and
compatible with the system's assembler (using SGS assembler format
all the way).  This way all you need to get running is the compiler.

2. I could bypass the system's assembler, output motorola format
(or whatever it is that gas accepts), and hack gcc and gas to
output/accept COFF-style directives (with .'s in front of them!).
Need to get both the compiler and the assmebler going.

3. I could leave gcc be and derive the COFF symbol entries from
the dbx symbol entries (gack! what a pain!).

4. What the heck, keep it BSD all the way to the loader.  You have
incompatible .o's, but at least you didn't need to hack on gas.
This would also simplify gcc wrt only knowing one assembler style.
Loader, however, would have to understand both BSD and native
formats, unless you wanted to translate your system libraries.

5. Go BSD all the way to the a.out.  Loader would need to stick something
on the front of an a.out to make the OS grok it.  You'd also need to
translate your system libraries into BSD format.  Gas could be pretty
much the same for any given processor and ld could be pretty much
the same across all systems.  RMS suggested this.

6. We could change gcc to generate a more generic symbol info output
from which you could easily generate either dbx or COFF output.
Assembler would have to know about different object formats,
but it would be in well-contained modules due to the more generic
nature of the input.  You'll need gcc & gas, but can use the native loader.

7. We could change gcc to instead of generating assembler ascii
output, simply transform the rtl into a machine specific rtl
that contained opcodes and addressing modes for the target machine,
retaining all symbol, file and line info.  This could be dumped
raw into a 'gnu object file' and later fed into an assembler/linker
for generation of relocatable or executable object files.
This approach avoids the assembler encoding/decoding step,
and makes it easy to generate whatever object file format you
want in the end.

I'm currently working on something along the lines of #6, but would
like to hear what everyone thinks about this.  I kinda lean toward
some variation on #7, though (as if you couldn't guess).

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

P.S.  I anyone's interested in my current version of gas, let me know.
The differences are fairly well confined to write.c with several
niggling changes in various places.