Debugging

Debugging

[James Colannino]

Hey everyone.  I have a small program that I had written a while ago in 
C to help me study for my Spanish class.  I decided to rewrite some code 
recently being that I have a little more experience, and found that the 
program does not function properly when I compile with -O2 optimizations 
(I'm using GCC.)  It works as it should, however, when there are no 
optimizations.  How exactly should I go about debugging this and 
figuring out what code is causing the problem?  I could compile it with 
the -g option and feed it to GDB, but then doesn't debugging not work 
very well when you've done optimizations?  Is -O2 a low enough level of 
optimization that I shouldn't have a problem?  Debugging is one of the 
many things I know extremely little about, so I'm very in the dark 
here.  Any input would be greatly appreciated :)  Thanks very much in 
advance.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[Steve Graegert]

On 1/29/06, James Colannino <james@colannino.org> wrote:
> Hey everyone.  I have a small program that I had written a while ago in
> C to help me study for my Spanish class.  I decided to rewrite some code
> recently being that I have a little more experience, and found that the
> program does not function properly when I compile with -O2 optimizations
> (I'm using GCC.)  It works as it should, however, when there are no
> optimizations.  How exactly should I go about debugging this and
> figuring out what code is causing the problem?  I could compile it with
> the -g option and feed it to GDB, but then doesn't debugging not work
> very well when you've done optimizations?  Is -O2 a low enough level of
> optimization that I shouldn't have a problem?  Debugging is one of the
> many things I know extremely little about, so I'm very in the dark
> here.  Any input would be greatly appreciated :)  Thanks very much in
> advance.

James,

debugging optimized code is very difficult for the following reasons
(to name a few):

   - due to a technique known as "common subexpression elimination"
you may not be able to stop on certain statements, although you think
it should be possible.,
   - instruction scheduling causes statements (typically those
resulting in load/store operations as found in computations of values)
to be moved around, i.e. move them close to the location where they
are used,
   - sometimes similar code fragments are merged so that the program
counter jumps to unexpected locations (often seen with return or break
statements).

There are other anomalies you may encounter when debugging optimized
code and I therefore recommend to increase the level of optimization
step by step beginning with -O0 and then to debug at each level to
check for unexpected values of variables and other bogus behavior.  I
am sure the GCC/gdb manual will reveal some helpful information about
debugging.

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultant {C/C++ && Java && .NET}
Office: +49 9131 7123988
Mobile: +49 1520 9289212

Re: Debugging

[Glynn Clements]

James Colannino wrote:

> Hey everyone.  I have a small program that I had written a while ago in 
> C to help me study for my Spanish class.  I decided to rewrite some code 
> recently being that I have a little more experience, and found that the 
> program does not function properly when I compile with -O2 optimizations 
> (I'm using GCC.)  It works as it should, however, when there are no 
> optimizations.  How exactly should I go about debugging this and 
> figuring out what code is causing the problem?  I could compile it with 
> the -g option and feed it to GDB, but then doesn't debugging not work 
> very well when you've done optimizations?  Is -O2 a low enough level of 
> optimization that I shouldn't have a problem?  Debugging is one of the 
> many things I know extremely little about, so I'm very in the dark 
> here.  Any input would be greatly appreciated :)  Thanks very much in 
> advance.

Debugging optimised code is hard, as many of the expressions and
variables which appear in the source code simply don't exist in the
optimised machine code.

One option is to identify exactly which optimisations are problematic
by enabling or disabling specific optimisations using the various -f
switches. That might give you some clues as to where the problems lie.

Probably the most common reasons for code breaking when optimisation
is enabled are aliasing bugs, i.e. where a storage location is
referenced in multiple ways. This is particularly common if you use
pointer type casts or "type-punning" (storing a value in one field of
a union then reading from another field with a different type). Try
using -fno-strict-aliasing to see if aliasing is the problem.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Debugging

[James Colannino]

Glynn Clements wrote:

>One option is to identify exactly which optimisations are problematic
>by enabling or disabling specific optimisations using the various -f
>switches. That might give you some clues as to where the problems lie.
>  
>

That's an awesome idea.  Thank you.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[James Colannino]

Patrick Leslie Polzer wrote:

>First, define "does not function properly".  Does it dump code, is there a
>logic error?
>  
>

Sorry; I should have explained myself more clearly.  It's a logic error 
(I think.)  What's weird is that I ran strace to compare the various 
system calls used with the un-optimized version vs. the optimized 
version, and they were both the same up to the point where the optimized 
one failed.  Of course that isn't a reflection of the actual machine 
code, so I guess that wouldn't necessarily help me out too much.

>Then go about finding the offending line(s) of code.
>Watch out for obscure tricks, side-effects, wild pointers and illegal casts.
>Compile with -Wall and, to enforce your discipline, treat every warning as
>-Werror.
>  
>

Without -Wall, I get no errors (I always do my best to get rid of 
warnings.)  I'll try it with -Wall though and see what happens.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[James Colannino]

James Colannino wrote:

>> Then go about finding the offending line(s) of code.
>> Watch out for obscure tricks, side-effects, wild pointers and illegal 
>> casts.
>> Compile with -Wall and, to enforce your discipline, treat every 
>> warning as
>> -Werror.
>
> Without -Wall, I get no errors (I always do my best to get rid of 
> warnings.)  I'll try it with -Wall though and see what happens.


*embarrased* using -Wall gave me the following error:

database.c:68: warning: implicit declaration of function `close'

That made me realize that I was trying to use the system call open 
instead of the standard library function fclose.  Once I fixed that, the 
code worked both when it was optimized and when it was not.  I think 
from now on I'll be using -Wall ;)  Thanks to everyone who responded.  
I'm glad I don't have to run this through a debugger....yet :)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb