|[2 earlier articles]|
|Re: Debug optimized code email@example.com (cr88192) (2008-09-17)|
|Re: Debug optimized code firstname.lastname@example.org (Walter Banks) (2008-09-17)|
|Re: Debug optimized code email@example.com (rcmetzger) (2008-09-17)|
|Re: Debug optimized code firstname.lastname@example.org (Stephen Horne) (2008-09-18)|
|Re: Debug optimized code email@example.com (Barry Kelly) (2008-09-19)|
|Re: Debug optimized code firstname.lastname@example.org (George Neuner) (2008-09-20)|
|Re: Debug optimized code DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-09-21)|
|Re: Debug optimized code email@example.com (Stephen Horne) (2008-09-22)|
|Re: Debug optimized code firstname.lastname@example.org (George Neuner) (2008-09-23)|
|Re: Debug optimized code email@example.com (Walter Banks) (2008-09-25)|
|Re: Debug optimized code firstname.lastname@example.org (kamal) (2008-10-01)|
|Re: Debug optimized code email@example.com (2008-10-04)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||Sun, 21 Sep 2008 21:35:08 +0200|
|Posted-Date:||23 Sep 2008 14:06:15 EDT|
Barry Kelly schrieb:
> The Delphi compiler, now (in theory) into its 20th version (but more
> like 12th or so after Turbo Pascals and Delphi 1, a different
> codebase), has always defaulted to debugging optimized code.
The typical advice to newbies is to disable optimizations for debugging.
> The general philosophy has been (1) don't do optimizations that aren't
> always safe, and (2) debug what actually runs on end-users' machines,
> not some artificial alternative program.
ACK, NACK. I never encountered any different behaviour in optimized
code, so that it's possible to debug with optimizations turned off.
After the bugs have been killed, the optimized code will pass the test
suites as well.
> It's worked well enough up to now. Note, however, that the Delphi
> compiler doesn't do huge amounts of optimization beyond constant
> folding, a little CSE, inlining, and a some strength reduction.
Not to forget instruction reordering, loop optimizations, register
variables, and lifetime reduction or overlays of variables, which
frequently result in "inaccessible value" messages while debugging.
Another optimization is available for the libraries, which come in debug
and retail versions. The retail version does not allow to step into
library code, so that it's recommended to also "use debug DCUs" for
Last not least the coder can access the optimization flags, and can
provide different source code in optimized mode, by using conditional
compilation. The same with side effects in assertions. Then it's not the
compiler, who is responsible for a different behaviour of the
non/optimized code ;-)
I appreciate very much the detailed settings of the various optimization
switches in the compiler configuration, which allow to turn off range
and overflow checks, assertions, and stack frames, independently from
the general optimization switches. Most of these switches also can be
turned on or off for parts of the code, so that it's possible to debug
selected statement sequences or subroutines. It's also possible to
quickly recompile selected units with different settings of the
switches, apart from the remaining modules. That separation allows to
trap bugs also in otherwise (compiler-)optimized code; perhaps this is
what you had in mind, when you recommended to debug the optimized Delphi
Return to the
Search the comp.compilers archives again.