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?"