Re: Debugging of optimized code

Stefan Monnier <monnier@di.epfl.ch>
Fri, 27 Jan 1995 04:01:03 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Debugging of optimized code conway@munta.cs.mu.OZ.AU (1995-01-24)
Re: Debugging of optimized code copperma@grenoble.rxrc.xerox.com (1995-01-24)
Re: Debugging of optimized code danhicks@aol.com (1995-01-26)
Re: Debugging of optimized code baynes@ukpsshp1.serigate.philips.nl (1995-01-26)
Re: Debugging of optimized code sam@ccnet.com (1995-01-27)
Debugging of optimized code ssimmons@convex.convex.com (1995-01-27)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
Re: Debugging of optimized code urs@engineering.ucsb.edu (1995-01-27)
Re: Debugging of optimized code miker@metaware.com (1995-01-24)
Re: Debugging of optimized code cef@geodesic.com (Charles Fiterman) (1995-01-25)
Re: Debugging of optimized code danhicks@aol.com (1995-01-27)
Re: Debugging of optimized code danhicks@aol.com (1995-01-29)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
[10 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: Stefan Monnier <monnier@di.epfl.ch>
Keywords: optimize, debug
Organization: Ecole Polytechnique Federale de Lausanne
References: 95-01-036 95-01-057
Date: Fri, 27 Jan 1995 04:01:03 GMT

SAND_DUANE@tandem.com wrote:
|One possible alternative is to construct for the user a program
|that does have a strong positional correspondence to the object
|program and looks something like a source program because it uses
|terminology borrowed from his program (variable names) and syntactic


This is a fairly interesting alternative excpet it might be a bit
strange and hard to understand in some cases. Fancy optimisations such
as those based on partial evaluation can totally rewrite the code and
it's often not easy at all to recognize the original code.


As another poster pointed out, maybe rethinking what a debugger should
offer might also be an alternative (but I have no idea what that other
thing should be)


Somebody else suggested reading about SELF. But SELF is different in
that there is always an "normal" representation available (the
compiled code is generated online and kept in a cache), so it is
possible to "deoptimize" the code and rerun it, ... it's not that it's
a bad solution (quite the contrary), but it's not too easy to
transpose the work done to "usual" compiler technology.


The original poster mentionned optimizing only parts of the code. I
think it's a great option. Pushing the idea further, the unoptimized
code could be kept in an intermediate format and interpreted (to
reduce binary size). The unoptimized version of the optimized code
could also be included with the binary so as to allow SELF-style
debugging.


I think the biggest problem with current C compiler technology is that
it doesn't want to switch to a more dynamic scheme, with incremental
compilation and such, as self, list and such do. It might have a
little speed impact (the biggest speed impact is due to the language
itself, I'm sure a C compiler wouldn't be much slowed down) but an
impressive improvement in debugging. When you can change the program
while it runs, it becomes a lot easier to debug (and the debugger
becomes easier to write, since the hard part is done: putting a
breakpoint is just inserting a call to the debugger, etc...)




Stefan
--


Post a followup to this message

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