grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (06/24/89)
the protoize package can be provide the framework for many other utilities. the best way to do this would be the option to produce a complete symbol table dump, listing all symbols, symbol classes, typedefs, etc etc. this information could be processed by other utilties, e.g., a modified protoize that doesn't require mods to the compiler itself. Another such utiliity would be an enhanced ``tags''. using the symbol table information, you could build a tags file that can be used for more sophisticated queries, e.g., scan through all functions, look for all local variables named `foo', whatever. also, such a tags program would be able to correctly grok C++ symbol names, something very difficult right now. it's unclear to me how much of this information could be gleaned from looking at the existing symbol table output generated using -g. That data doesn't make relations between e.g., line numbers & symbol names. in any case, providing a standardized symbol table dump utility would subsume the changes needed for protoize & serve other purposes too. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
meissner@tiktok.dg.com (Michael Meissner) (07/05/89)
In article <GRUNWALD.89Jun23230127@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: | the best way to do this would be the option to produce a complete | symbol table dump, listing all symbols, symbol classes, typedefs, etc etc. Macros used would also be useful, as would eliminating either all externals that don't create storage, or just the unused externals. | this information could be processed by other utilties, e.g., a modified | protoize that doesn't require mods to the compiler itself. Here, here.... | Another such utiliity would be an enhanced ``tags''. using the symbol | table information, you could build a tags file that can be used | for more sophisticated queries, e.g., scan through all functions, | look for all local variables named `foo', whatever. Also it would provide the necessary information for a cross reference tool, and a global consistency checker (ala lint). | it's unclear to me how much of this information could be gleaned from | looking at the existing symbol table output generated using -g. That | data doesn't make relations between e.g., line numbers & symbol names. Besides the format of -g output varies from machine to machine (ie, some machines use different assembler directives, and also the basic dbx/sdb/gdb differences). | in any case, providing a standardized symbol table dump utility would | subsume the changes needed for protoize & serve other purposes too. The one problem I have with the current format, is the choice of the suffix (.p means pascal on many systems, and if you have make rules for both C and Pascal, make might think the file.p left over from a previous run is a Pascal source and feed it to pc). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?