Re: debugging optimized code

Pierre Mai <>
6 Oct 1998 15:24:49 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: Debugging optimized code (1990-07-30)
Re: Debugging optimized code (1990-07-31)
debugging optimized code (Caroline Tice) (1998-09-18)
Re: debugging optimized code (Steve Simmons) (1998-09-22)
Re: debugging optimized code (Quinn Tyler Jackson) (1998-09-24)
Re: debugging optimized code (Michael Ross) (1998-09-24)
Re: debugging optimized code (Pierre Mai) (1998-10-06)
| List of all articles for this month |

From: Pierre Mai <>
Newsgroups: comp.compilers
Date: 6 Oct 1998 15:24:49 -0400
Organization: Technical University Berlin, Germany
References: 98-09-124
Keywords: optimize, debug
X-Server-Date: 6 Oct 1998 17:09:13 GMT
X-PGP-Fingerprint: 17 2D 00 93 8B C8 57 57 A7 D7 CD E9 3A EA 6E 4C

"Quinn Tyler Jackson" <> writes:

> 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."

> [There are debuggers that work on optimized code. But they don't run on
> PCs. -John]

An interesting paper on a new approach to bridging the semantic gap
between the programmer and the machine (and related problems) is
"OPTVIEW: A New Approach for Examining Optimized Code" by Caroline
Tice and Susan L. Graham (both UCB) at PASTE'98 (proceedings are in
volume 33 number 7 (June 1998) of ACM SIGPLAN, probably also available
via ACM's Digital Library at


The task of mapping between source programs and machine code, once the
code has been optimized and transformed by a compiler is often
difficult. Yet there are many instances, such as debugging optimized
code or attributing performance analysis data to source lines, when it
is useful or necessary to understand at the source level what is
occurring in the binary. The standard approach has been for tools to
attempt to map directly from the optimized binary to the original
source. Such mappings are often fragile, and sometimes inaccurate or
misleading. We suggest an alternative approach. Rather than mapping
directly between the original source and the binary, we create a
modified version of the source program, still recognizable, but
updated to reflect some of the effects of optimizations, thus
facilitating mapping from the binary. We have implemented a tool,
Optview, to demonstrate and test these ideas.

Regs, Pierre.
Pierre Mai <>

Post a followup to this message

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