Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!thirdi!peter
From: peter@thirdi.UUCP (Peter Rowell)
Newsgroups: comp.lang.c++
Subject: Re: implementation/mips/dec/ultrix
Message-ID: <478@thirdi.UUCP>
Date: 25 Sep 89 23:56:37 GMT
References: <2348@hub.UUCP> <3838@itivax.iti.org>
Reply-To: peter@thirdi.UUCP (Peter Rowell)
Organization: Third Eye Software, Menlo Park, CA
Lines: 88

I must make some corrections to remarks made by Steve Simmons:

In article <3838@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes:
>The DEC 2100/3100/5400/5800 series and MIPS use a custom symbol table
>format from Third Eye Software.

This is not exactly correct.  MIPS has made major modifications to
Third Eye's original work.  Much of the complexity was introduced by
MIPS.  I believe they were attempting to solve the problem of multiple
instances of symbols from included .h files.  If you want details,
call them.

> It is different from both BSD stabs and AT&T COFF.

This is because it is used to isolate Third Eye's CDB debugger from
the insanity of BSD and AT&T (and System III, and Siemens, etc.)
We currently work with 5 totally differnet symbol tables with
about 15 minor (or at least less major) variations.

> One writer quoted Mark Linton, the creator of stabs,

Actually, I believe he is the creator of the "type information in
the string table" hanging off of the stabs, not of "stabs" themselves.
The basic BSD stabs, in their current "shape" go back to at least
1982, possibly earlier.

> ... calling the format ``an exercise in complexity''.

Mark is welcome to his opinion.  Although I cannot speak for what MIPS
has done with Third Eye's work, I can say that our standard format is
40% smaller than either BSD of COFF symbol tables and that it allows
the programmer to bring the debugger up almost instantaneously after we
have built the table.  Our symbol table was specifically designed for
debugger support in the real world (where poeple keep changing all
sorts of silly little things in their symbol tables for no apparent
reason).

> GCC/G++ won't run on these until either someone decides the port
> is worth the effort of rewriting all the symbol table stuff or
> DEC/MIPS goes to a more standard format.

Standard? In UNIX?  Which "standard" did you have in mind?

COFF? They are about to have to make a change because there aren't
enough bits to handle full ANSI C type qualifiers (but that's OK,
there were already 4 variations on COFF, not counting hacks by
AT&T licensees).

BSD?  Which one?  Straight BSD?  Or Sun's BSD (Which symbol table? SunOs
3.1, 3.5, 4.0, or the wonderful one that they introduced for the 386i?).
How about the changes made by DEC did when Ultrix first came out?  Those
were interesting.

HP-UX? There's a symbol table will give you pause to think......

Our experience is that most manufacturers are *proud* of the
"improvements" they have made and that they think everyone else is
wrong for not following their pioneering lead.  Bah humbug!  We have
been porting CDB for 6.5 years, we work on 103 combinations of
cpu/os/mfg/compiler.  You can say anything you like about UNIX, but the
use of the word "standard" creates an instant oxymoron.

>So there are two courses of action:
>One, modify the gnu compiler and debugger to understand the symbol table
>format.  This is likely to meet with some resistance from RMS et al, based
>on their extremely lukewarm support for the COFF stuff.

Which means that your above use of the word "standard" should be
read as "equivalent to BSD".  

>The other is to adopt a robotussin-like solution and bring over the gnu
>binutils (gas, nm, ld, etc).  This may not be feasible, as it's not at all
>clear where the MIPS optimisers does their real work.  If part of it is
>in the assembler, there may be problems.

There may be problems.

>Steve Simmons		          scs@vax3.iti.org
>Industrial Technology Institute     Ann Arbor, MI.
>"Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai

The real world of UNIX is much messier than living in a single,
homogeneous network would ever lead you to believe.

------------------------------------------------------------------------------
Peter Rowell				peter@thirdi.UUCP
Third Eye Software, Inc.		(415) 321-0967
Menlo Park, CA  94025   	"Well, it *looks* pretty, but does it work?"