Re: Debugging of optimized code

conway@munta.cs.mu.OZ.AU (Thomas Charles CONWAY)
Tue, 24 Jan 1995 07:09:29 GMT

          From comp.compilers

Related articles
Debugging of optimized code SAND_DUANE@tandem.com (1995-01-09)
Re: Debugging of optimized code brent@jade.ssd.csd.harris.com (1995-01-23)
Re: Debugging of optimized code bill@amber.ssd.csd.harris.com (1995-01-13)
Re: Debugging of optimized code milt@Eng.Sun.COM (Milton Barber) (1995-01-23)
Re: Debugging of optimized code snl@RIF.ndim.edrc.cmu.edu (Sean Levy) (1995-01-23)
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)
[16 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: conway@munta.cs.mu.OZ.AU (Thomas Charles CONWAY)
Keywords: optimize, debug
Organization: Computer Science, University of Melbourne, Australia
References: 95-01-036
Date: Tue, 24 Jan 1995 07:09:29 GMT

In response to this question of how to debug optimised code I can
contribute the following.


The problems of debugging optimised code due to code motion,
inlining, etc are very difficult to compensate for in source level
debugging of imperative languages. However, for declarative languages
the problem is much simpler.


In a purely declarative language, the outputs of a function (or predicate)
are solely dependent on the inputs. This property gives rise to the
idea of declarative debugging (a variant of which is called rational
debugging). The idea is that if to evaluate a function f(x) we have
to evaluate g(y) and h(z), the debugger can ask the programmer a series
of questions like the following:


f(x) = <some value>, is this correct (y/n)? n
g(y) = <some value>, is this correct (y/n)? y
h(z) = <some value>, is this correct (y/n)? y


If g and h are the only functions f calls, and they both
evlauate correctly, then the bug must lie in the way the f
composes the results of g and h (or possibly in the arguments
passed to g and h).


If you make smarter use of data dependecy information, you could
extend the technique further and have the programmer indicate which
part of the result of f(x) is incorrect, and the debugger can take
the programmer straight to the place in the code where the relevant
value was constructed.


I expect that as declarative languages become more important and better
implemented, we will see techniques such as declarative debugging become
more widely understood. The point with declarative debugging is that it
is independent of how the underlying implementation *does* the computation,
and depends only on the specification of what the program should compute
in the program.


I'm not sure that I've done full justice to declarative debugging and how
it copes with optimising implementations. If you have questions or think
I've left something out, I'd be pleased to engage in further communication
on the subject.


Thomas
--
Thomas Conway conway@cs.mu.oz.au
--


Post a followup to this message

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