Related articles |
---|
[3 earlier articles] |
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) |
From: | Pierre Mai <pmai@acm.org> |
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" <qjackson@wave.home.com> 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 http://www.acm.org/).
Abstract:
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 <dent@cs.tu-berlin.de> http://home.pages.de/~trillian/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.