mcg@INTEL-IWARP.ARPA (10/16/88)
I'm retargeting gcc 1.29 to a new architecture, and while the process is, by and large, going fairly smoothly, I sometimes run into bugs that are extremely difficult to fix. These usually are bugs caused by subtle ill-formed aspects of the machine-description. The manifest themselves by the compiler decising to abort at some stage because of invalid RTL. For example, the most recent problem I've been tearing my hair out over is an abort from insn_extract() from regclass(). The former routine is clearly getting a bad insn, but there doesn't seem to be a conveniant way of isolating the region of RTL that is causing the problem, much less the original RTL template that are at fault. The debugging dumps are generally far too impenetrable to be of assistance, unless I factor the program down to a tiny subset of its original size. 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. S. McGeady mcg@iwarp.intel.com (mcg@intel-iwarp.arpa) mcg@omepd.intel.com tektronix!ogcvax!omepd!mcg
randy@WHEATIES.AI.MIT.EDU (10/19/88)
When debugging gcc, I have almost always managed to get the uid of
the rtl which causes the abort (by going up a couple of stack frames
and doing a pr). With this, the rtl dumps are very valuable; you
simply search for the insn uid of the deadly rtl in the dump from
the last pass before the crash. Usually, this will show you which
part of the md file is screwing up (eg. this piece of rtl *should*
match this define_insn, but it doesn't. Why not?). In your case,
insn_extract is called with a specific instruction. Work out
which define_insn in the machine description it matches, and look at
it. A careful comparision of the insn insn_extract is called with
vs. the one in the machine description is matches will usually show
you the problem. (Are any of these suggestions useful?)
I will say that debugging gcc is harder than debugging any other
program I've worked with (for the reasons you've mentioned).
However, this strikes me as reasonable for a program of the
complexity of an optimizing C compiler. In fact, I think gcc is
extremely cleanly written, and as a result it is much easier to
debug than a less cleanly written optimizing compiler.
-- Randybunda@cs.utexas.edu (John Bunda) (10/21/88)
This question has come up several times now. I had emailed some replies to these, thinking it wasn't general interest, but it seems... The function debug_rtx() takes an rtx argument. If you are using a reasonable debugger (viz gdb), you should be able to muck around and find some rtx that seems responsible for a particular problem (hint - the name insn comes up a lot!). In gdb you can then type "print debug_rtx(insn)" for example to see a nice rtl display of the object. If you don't have a decent debugger, replace the abort() that is forcing the dump with an appropriate call to debug_rtx(). (in fact, i might be so bold as to suggest a #ifdef DEBUGGING or some such to have this option there all the time...) -John -- ................................... John Bunda UT CS Dept. bunda@cs.utexas.edu Austin, Texas