3B1/7300 Development set wanted

[Steve Simmons]

dts at quad.uucp (David T. Sandberg) writes:

>In article <10129 at zodiac.ADS.COM> neville at hebron.ADS.COM (Neville Newman) writes:
>:In article <399 at quad.uucp> dts at quad.uucp (David T. Sandberg) writes:

>:Now i get to ask - why?  Wouldn't it be better in the long run to
>:get of couple of compiler writers to modify gas (GNU Assembler)
>:and family to generate/understand Unix-PC object files?

>Well, I can't speak for anyone else, but I avoid all GNU software on
>principle - I don't agree with Stallman's ideas.  Besides, there's a
>lot more to the development set than just a compiler and assembler.

Speaking as one who seriously looked at doing the above:

There are a number of utilities from the FSF binary utilities that would
need to be ported:  gas (assembler) and ld (the linker) are absolutely
required.  In addition strip, nm, and size would be nice (and are
trivial).

The primary problem is the symbol table (a.k.a. 'stab') format.  FSF
binutils are (were? I haven't looked recently) firmly based on UC Berkeley
format symbol tables.  AT&T uses the Common Object File Format (COFF).
Since /lib/libc.a and its friends are all firmly COFF files, there are
two choices:

Modify gas to output COFF format, modify ld to read/output COFF format,
modify strip/nm/size to use COFF format.  A lot of work.  Or...

Use a FSF utility called 'robotussin' (coff medicine) to translate the
COFF format lib.a files into BSD stab files.  Change all your lib.a files,
then happily run with FSF binutils.

At first the latter sounds very attractive.  Be warned, tho, there is a
price: you lose the shared libraries.  Since this results in radically
larger object files and executables, you pay a severe penalty on small
memory/small disk machines (like, for example, the Unix PC).

There might be a third solution: follow the first route, but hack FSF ld
to understand and link 3b1 shared libraries.  But to do that you need
the development set, and if you have the development set you don't need
to do it -- so nobody's done it.  Yet.

>From scs Tue Dec 19 11:34:59 1989
From: scs
Newsgroups: comp.sys.att,unix-pc.general,misc.wanted
Subject: Re: 3B1/7300 Development set wanted
Keywords: 3B1, 7300, UNIX-PC, Development set
Distribution: usa
References: <4309 at rtech.rtech.com> <399 at quad.uucp> <10129 at zodiac.ADS.COM> <401 at quad.uucp>
Status: OR

dts at quad.uucp (David T. Sandberg) writes:

>In article <10129 at zodiac.ADS.COM> neville at hebron.ADS.COM (Neville Newman) writes:
>:In article <399 at quad.uucp> dts at quad.uucp (David T. Sandberg) writes:

>:Now i get to ask - why?  Wouldn't it be better in the long run to
>:get of couple of compiler writers to modify gas (GNU Assembler)
>:and family to generate/understand Unix-PC object files?

>Well, I can't speak for anyone else, but I avoid all GNU software on
>principle - I don't agree with Stallman's ideas.  Besides, there's a
>lot more to the development set than just a compiler and assembler.

Speaking as one who seriously looked at doing the above:

There are a number of utilities from the FSF binary utilities that would
need to be ported:  gas (assembler) and ld (the linker) are absolutely
required.  In addition strip, nm, and size would be nice (and are
trivial).

The primary problem is the symbol table (a.k.a. 'stab') format.  FSF
binutils are (were? I haven't looked recently) firmly based on UC Berkeley
format symbol tables.  AT&T uses the Common Object File Format (COFF).
Since /lib/libc.a and its friends are all firmly COFF files, there are
two choices:

Modify gas to output COFF format, modify ld to read/output COFF format,
modify strip/nm/size to use COFF format.  A lot of work.  Or...

Use a FSF utility called 'robotussin' (coff medicine) to translate the
COFF format lib.a files into BSD stab files.  Change all your lib.a files,
then happily run with FSF binutils.

At first the latter sounds very attractive.  Be warned, tho, there is a
price: you lose the shared libraries.  Since this results in radically
larger object files and executables, you pay a severe penalty on small
memory/small disk machines (like, for example, the Unix PC).

There might be a third solution: follow the first route, but hack FSF ld
to understand and link 3b1 shared libraries.  But to do that you need
the development set, and if you have the development set you don't need
to do it -- so nobody's done it.  Yet.

--

Steve Simmons         Just another midwestern boy
scs at vax3.iti.org  -- or -- ...!sharkey!itivax!scs
"Think of c++ as an object-oriented assembler..."