Re: Debug optimized code

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Sun, 21 Sep 2008 21:35:08 +0200

          From comp.compilers

Related articles
[2 earlier articles]
Re: Debug optimized code cr88192@hotmail.com (cr88192) (2008-09-17)
Re: Debug optimized code walter@bytecraft.com (Walter Banks) (2008-09-17)
Re: Debug optimized code rcmetzger@grandecom.net (rcmetzger) (2008-09-17)
Re: Debug optimized code sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-18)
Re: Debug optimized code barry.j.kelly@gmail.com (Barry Kelly) (2008-09-19)
Re: Debug optimized code gneuner2@comcast.net (George Neuner) (2008-09-20)
Re: Debug optimized code DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-09-21)
Re: Debug optimized code sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-22)
Re: Debug optimized code gneuner2@comcast.net (George Neuner) (2008-09-23)
Re: Debug optimized code walter@bytecraft.com (Walter Banks) (2008-09-25)
Re: Debug optimized code kamalpr@hp.com (kamal) (2008-10-01)
Re: Debug optimized code anton@mips.complang.tuwien.ac.at (2008-10-04)
| List of all articles for this month |
From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Sun, 21 Sep 2008 21:35:08 +0200
Organization: Compilers Central
References: 08-09-076 08-09-099
Keywords: optimize, debug
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
debugging.


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


DoDi



Post a followup to this message

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