johnl@ima.UUCP (03/07/87)
Has anyone built a debugger that allows debugging of optimized
compiled code at the source level? That is, a debugger that reverses
the transformations made by the compiler, so that execution looks to
the user like results are stored promptly, etc. (I realize that
sometimes this is not possible, e.g., once a variable is "dead", its
value may be thrown away. But then, the debugger could capture and
store the value...)
Dale Worley Cullinet Software
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
ARPA: cullvax!drw@eddie.mit.edu
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (03/12/87)
About 7 years ago I did some very preliminary studies involving the
BLISS-32 code generator while I was at Digital. I managed to convince
myself that it was possible to derive source code from the optimized
object code, however, one would have to make extensive use of
heuristics.
Unfortunately, I was unable to convince management that there was
sufficient payback to warrant a project. (I used the concept of filtering
optimized object code through a source generator, and then filtering
that back through the optimizer. They weren't interested: the existing
optimizations were good enough, and I was proposing orders of
magnitude more time to do a compile.)
The heuristics would only be good for a certain class of compilers
and their code generators. The peephole optimizers and cross jumping
done by different compilers would create an enormous explosion of
possible source codes.
I eventually came to the conclusion that there are two possible uses
of 'compiling object into source'. 1) As a study in a given compiler's
effectiveness at handling particular classes of programs. and 2)
as an analysis tool to see how a computer would execute a program.
The original thought of increasing code optimization would turn out
to be an impractical use; with a good optimizer in the first place,
you would not obtain practical results after the second iteration.
If you're interested, I'll try to dig up my notes.
--Bruce Dawson
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (03/13/87)
You should order the paper "Interactive Source-Level Debugging of Optimized
Programs", by Polle Zellweger from the folloowing address:
Xerox Corporation, Palo Alto Research Center
Communications Group
3333 Coyote Hill Road, Palo Alto, CA 94304.
I heard Polle discuss her paper. As I recall, the upshot was that
optimized debugging wasn't worth the trouble.
But then that's just one opinion....
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (03/24/87)
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
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-request