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
tiemann@SUN.COM (Michael Tiemann) (09/26/89)
I must make some corrections to remarks made by Steve Simmons: And I'll add mine where appropriate. 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. Sun did this by a simple extension of stabs. What do I mean by simple? I mean that if the debugger just ignores stabs it does not understand, the right thing still happens; it just happens with more memory being used. If it was MIPS's fault for not recognizing that a similarly trivial extension could be made to achieve this functionality, then let flame MIPS. If it was not immediately apparent how this could be done for the 3rd-Eye format, or it was not in fact trivial to add, then the blame lies with 3rd-Eye (modulo MIPS's culpability for selecting it). > 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.) I the same way that Siberia isolates one from the insanity of San Franciso, Paris, Berlin or Barbados? > ... 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). Well, CDB does not come up instantly on the HP 9000/825 (Spectrum), at least for debugging GCC. I will grant that it comes up several times faster than DBX does on the Sun4 (loading the same program), but not nearly as fast as GDB, with incremental symbol-table loading. Amazing that Randy Smith could get all that performance without having to botch the symbol table format. > 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? Note that he said ``more'' standard. Not absolute standard. 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). An old flame. I bitched about this >1 year ago, when there were also not enough type bits for virtual functions, pointers to members, baseclass types, overloaded operators, etc. I think that people at AT&T were listening, because they are going to fix this. >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". I like using an operational definition in this case :-) Michael