silber@voodoo.ucsb.edu (09/16/89)
-Message-Text-Follows- I ftp'd the files for v. 1-3.5 and TeX'd the gcc-info.tex file; it says under the 'bullet' for mips that DEC/mips is an exception not yet supported. CAN ANYONE SUPPLY INFO ON AN FTP'able version for DEC/MIPS/DECSTATION3100 ???????
scs@itivax.iti.org (Steve Simmons) (09/20/89)
silber@voodoo.ucsb.edu writes: >I ftp'd the files for v. 1-3.5 and TeX'd the gcc-info.tex file; >it says under the 'bullet' for mips that DEC/mips is an exception >not yet supported. CAN ANYONE SUPPLY INFO ON AN FTP'able version >for DEC/MIPS/DECSTATION3100 ??????? Others have been asking similar questions about gdb, etc. The following is a summary of the info I received on the topic a few months back. The DEC 2100/3100/5400/5800 series and MIPS use a custom symbol table format from Third Eye Software. It is different from both BSD stabs and AT&T COFF. One writer quoted Mark Linton, the creator of stabs, calling the format ``an exercise in complexity''. 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. So the short answer is "it doesn't exist and nobody is working on it." Now the long answer. IMHO, DEC and MIPS are unlikely to change to make GNU users happy. 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. On the other hand, there are a lot of DECmips and MIPSmips users out there. Since MIPS says they're selling the software suite as well as the risc technology, there will probably be more as time goes by. 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. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
grunwald@foobar.colorado.edu (Dirk Grunwald) (09/21/89)
This is not completely true. You can use gcc and g++ on the MIPS box. You can generate line-location information for the MIPS box. What you can't do is provide SDB/DBX information directly. The current MIPS assembler does not have a debugging (SDB/DBX) interface. From correspondence with various people, MIPS plans on adding this feature, but we'd be ill advised to hold our collective breath. Alternate solutions require producing the magic .T file, to be consumed by the as1 pass. This, while difficult, is not insurmountable. The other alternate, having GAS mimic the function of the MIPS assembler, seems more difficult. The MIPS assembler is fairly sophisticated. I'm looking at the complexity of generating the .T file - I don't know how hard this is yet, but I do have A Guiding Example. If someone else is burning to do this, please go right ahead - mail me and I'll see if I can't disseminate my information to you. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
evans@testmax.ZK3.DEC.COM (Marc Evans Ultrix Q/A) (09/22/89)
>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. Depending upon the compiler options selected, soem ofthe opts are done in the assembler... ========================================================================== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)893-8481 Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076 ==========================================================================
peter@thirdi.UUCP (Peter Rowell) (09/26/89)
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?"
scs@itivax.iti.org (Steve Simmons) (09/27/89)
peter@thirdi.UUCP (Peter Rowell) writes: >I must make some corrections to remarks made by Steve Simmons: [[and makes a long rebuttal to my article <3838@itivax.iti.org]] Peter, I intended no insult. As noted in my posting, I was passing on a complation of 3rd-party comments on the MIPs symbol table format. My apologies for posting somewhat erroneous data; your corrections are appreciated. -- Steve -- + Steve Simmons scs@itivax.iti.org + + Industrial Technology Institute Ann Arbor, MI. + + "Even a dog can shake hands." -- Warren Zevon +