[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.
Stefan
- RE: [22.1.90]: Point before start of properties, (continued)
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/19
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Richard Stallman, 2008/02/21
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/21
- Re: [22.1.90]: Point before start of properties, Stephen J. Turnbull, 2008/02/21
- [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties),
Stefan Monnier <=
- Re: [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties), Andreas Schwab, 2008/02/22
- [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties), Stephen J. Turnbull, 2008/02/22
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/22
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/22
- Re: [22.1.90]: Point before start of properties, Miles Bader, 2008/02/22
- Re: [22.1.90]: Point before start of properties, Richard Stallman, 2008/02/23
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/23
- Re: [22.1.90]: Point before start of properties, Richard Stallman, 2008/02/24
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/24
- Re: [22.1.90]: Point before start of properties, Richard Stallman, 2008/02/25