[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OT] Deugging optimized code (was: [22.1.90]: Point before start of prop

From: Stefan Monnier
Subject: [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties)
Date: Fri, 22 Feb 2008 10:18:13 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>> Debugging optimized code is [...] a wrong question.
> Intel thanks you for your marketing of their future products!

I guess I do, but I don't think you quite understood what I meant:
I indeed value correctness over speed (and really, Emacs is a good
example of low-speed program, both as a program (difficult to make it
fly) and as a language design&implementation); but my comment was
pointing out something else about "debugging optimized programs".
Basically such debugging comes up in a few different cases:

1 - the need to debug a program that is too-slow if not optimized.
2 - a bug in the compiler optimization phase.
3 - a bug that is depends on an unspecified behavior in the language,
    and which happens not to be triggered unless some optimization phase
    of the compiler is used.
4 - a timing-dependent bug.

Case 1 is best solved by using a different approach to debugging:
instead of a GDB-style approach (where the compiler does its thing
regardless of debugging and then the debugger is expected to be able to
present the result in a meaningful manner to the programmer), you can
take an Edebug-style approach where the *source* program is annotated
(maybe on the fly and then recompiled/reoptimized), in which case there
may not even be *any* need for "debugging-info" and the
compiler&optimizer can hence be made simpler and the debugger can be
(somewhat) independent from the compiler.  That's what I meant by "a
wrong question": instead of solving the impossible debugging problem
after-the-fact (after the optimizer has done its thing), you can solve
a different problem (annotate the source program) instead.

As for the other 3 situations, here's my take on it:
2 - use better software engineering technology, based on formal systems,
    to rule out these possibilities.  That's my area of research ;-)
3 - use a better specified language.
4 - There are all kinds of approaches to debug and/or formally verify
    race conditions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]