Re: debugging optimized code

"Quinn Tyler Jackson" <qjackson@wave.home.com>
24 Sep 1998 00:20:03 -0400

          From comp.compilers

Related articles
Debugging optimized code lyle@cse.ogi.edu (Lyle Cool) (1990-07-24)
Re: Debugging optimized code jac@paul.rutgers.edu (1990-07-27)
Re: Debugging optimized code johnson@cs.uiuc.edu (Ralph Johnson) (1990-07-30)
Re: Debugging optimized code pattis@cs.washington.edu (1990-07-30)
Re: Debugging optimized code jclark@src.honeywell.com (1990-07-31)
debugging optimized code cmtice@cs.berkeley.edu (Caroline Tice) (1998-09-18)
Re: debugging optimized code simmons@nortel.ca (Steve Simmons) (1998-09-22)
Re: debugging optimized code qjackson@wave.home.com (Quinn Tyler Jackson) (1998-09-24)
Re: debugging optimized code michael.ross@intel.com (Michael Ross) (1998-09-24)
Re: debugging optimized code pmai@acm.org (Pierre Mai) (1998-10-06)
| List of all articles for this month |

From: "Quinn Tyler Jackson" <qjackson@wave.home.com>
Newsgroups: comp.compilers
Date: 24 Sep 1998 00:20:03 -0400
Organization: Compilers Central
Keywords: optimize, debug

>I'm looking for information about debuggers that work correctly
>on optimized code. If anyone knows of existing debuggers that
>do so I would appreciate information about them. Thanks.


How do you define "correctly?"


In my experience with C++ compilers and their associated interactive
debugging environments, the debugging of optimized code has proven so
cumbersome that I have taken to turning off compiler optimizations
altogether, even in release builds, in order that release versions of
the product behave exactly like the debugging versions. They behave
correctly -- which is their main problem, as I see it.


Borland's C++, for instance, optimizes variables out of existence so
quickly that one must insert break points at just the right spot if
one wants to inspect their contents. Unfortunately, with
optimizations turned on, what "just the right point" is becomes rather
unknowable, or a matter of wishcraft, rather than science, since lines
of source code as I know them as a programmer become meaningless when
the compiler unrolls loops, uses registers for variables, inlines
functions, or whatever other magic quux the compiler decides will gain
some speed. So, although the debugger is being "correct" in the sense
that it allows single stepping to jump to places I never would have
guessed, or skips chunks of code that have been optimized into the
ether, it is not being correct in the sense that I can follow the
program flow during the debugging session.


Take for instance the following code:


// code begins


        #include <iostream.h>


        int multiply_the_slow_way(int a, int b)
        {
                int c = 0;
                for(int i = 0; i < b; c += a, i++);
                return c;
        }


        int main(void)
        {
                cout << multiply_the_slow_way(5,2) << endl;
        }


// code ends


With the proper compiler settings in Visual C++ 5.0, the compiler is
able to figure out what I am up to, and "correctly" and effectively
produces the following code:


        int main(void)
        {
                cout << 10 << endl;
        }


Single stepping through this in the debugger, however, produces mild
confusion in my finite mind, and so, I turn off optimizations to test
my code in the debugger. This is a simple example, to be sure, but
given enough of these correct but confusing optimizations, I am left
unable to correctly debug the system with any kind of measurable
certainty, because the debugger behaves correctly by a machine's
standards. And so, I would say, "the Yoyodyne compiler's debugger
operates correctly on optimized code, but not correctly on the
unoptimized coder."


--
Quinn Tyler Jackson


email: qjackson@wave.home.com
url: http://www.qtj.net/~quinn/
ftp: qtj.net
[There are debuggers that work on optimized code. But they don't run on
PCs. -John]








--


Post a followup to this message

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