Re: Debuggers

decvax!decwrl!mips!himel (Mark I. Himelstein)
Mon, 23 Mar 87 15:09:22 PST

          From comp.compilers

Related articles
Debuggers think!cullvax!drw%eddie.mit.edu (1987-03-07)
Re: Debuggers harvard!rutgers!sri-unix!ctnews!mitisft!markb (1987-03-12)
Re: Debuggers harvard!rutgers!spam!ames!ucbcad!ucbvax!decvax!vir (1987-03-15)
Re: Debuggers decvax!decwrl!mips!himel (1987-03-23)
Debuggers fabio@dcs.edinburgh.ac.uk (1991-08-08)
Re: debuggers zstern@adobe.com (1993-11-11)
Re: debuggers shyamal@seas.smu.edu (1993-11-11)
Re: debuggers wjw@eb.ele.tue.nl (1993-11-11)
debuggers ssimmons@convex.com (1993-11-11)
Re: debuggers sommerfeld@apollo.hp.com (1993-11-11)
[3 later articles]
| List of all articles for this month |

Date: Mon, 23 Mar 87 15:09:22 PST
From: decvax!decwrl!mips!himel (Mark I. Himelstein)

I just wanted to add some notes to the previous comments on debugging optimized
code. At MIPS we planned for debugging optimized code by providing data
structures to include information to map code back to source even after
it was heavily modified by the optimizer (e.g. we save one line information
datum per instruction of text in a very compact form so that we can
map it to the source code generating it -- or approximate if more than
one source line contributed to a single instruction). We also provided for
levels of debugging information akin to levels of optimization. So far, we've
noted that the only people who need to debug optimized code are
the compiler group and the level of debugging you get with just letting
the debugging info go where it will after optimization is sufficient to
fix the optimizer when it's broken (not the best, but sufficient).
People seem satisfied to debug non-optimized code and then re-compile
their program when they think it works-- some may even keep two copies
of the binaries around, one for debugging and one for production.


So we do not provide complete debugging for optimized code. In order to
do so we would need two things: fill out our optimization tables describing
register mapping on a basic block boundary, procedure inlining, etc. and
decide on a way to present a coherent view of a program written one way but
appearing another way at debug time. The former would consume a large amount
of space and latter is probably an AI project.


Mark I. Himelstein
decwrl!mips!himel
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.