Date: Wed, 28 Jan 1998 13:21:55 +0200 (IST) From: Eli Zaretskii To: cterry AT plinet DOT com cc: djgpp AT delorie DOT com Subject: Re: djgpp/rhide acting strange In-Reply-To: <34CD9FD1.5419@plinetl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 27 Jan 1998, Charles Terry wrote: > > Check your compiler flags. Use `-g' and DO NOT use `-O*', > > `-fomit-frame-pointer', or any other optimization options. They > > are known to make debugging screwy. > > > The timess I've experienced the same problems are > 1) When I'm trying to access a class member > You have to use this->var or *this > 2) Also trying to access a class member and get a global of the same > name. Inasmuch as optimizations can make debugging a bit harder, I would still suggest to debug the code compiled with exactly the same switches as you use for production. Debugging an unoptimized code, then compiling it with -O2 for the release is like using all possible safety equipment when learning to swim in shallow waters, then throwing all that gear away when you first jump into the deep sea. Optimization switches cause the compiler to emit different code. The better the optimizer, the more different is the code. So by debugging an unoptimized version you are just debugging a different program. Fortunately for us, GCC allows to debug optimized code, unlike other compilers. I think this is a great feature, even if it causes some inconveniences. These inconveniences are, in my experience, small and usually can be solved quite easily. For example, if a local variable is optimized away, you can usually get its value by using other variables and GDB's ability of computing expressions. Personally, I would switch to debugging an unoptimized version only when I get such a wierd behavior that I'm totally lost, and only for as long as it takes to understand what the heck is going on.