🚀 go-pugleaf

In a recent posting to bug-gcc, mcg@intel-iwarp.arpa (S. McGeady) wrote:
>So, my question is, does anyone have tools, tips, sympathy, or other
>advice for someone coming up to speed on debugging gcc?  Much thanks
>for any help.

I have much sympathy, but that's about all I can offer.  A good debugger
helps some, but most debuggers will be frustrated by the extensive use of
humongous macros from the tm-*.h files (and elsewhere).  Also, I have just
learned that function-inlining causes serious problems for SDB/COFF debuggers.

BTW, reading the GCC manual helps immensely.

I have been thinking that once I finish up all of the other little GNU projects
I have on my plate now, such as getting GCC, G++, GDB, GDB+, and GAS all up
and stable on our VME532 systems, (not to mention the work that I'm actually
being paid to do) then I thought that it would be a nice idea to write a new
front end for GCC which would accept "rtl-dump" style code.  With such a front
end you could create rtl-dumps from programs which bomb the compiler (or which
cause bad code to be generated) and then edit these dumps down bit-by-bit until
you isolated the sinister rtl code which causes the optimization stages or your
particular back end to mess up.

Has anyone else though of doing this?

Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg