Why GCC/ GDB ignore a normal C statement?

Why GCC/ GDB ignore a normal C statement?

[Huaxia Zhao]

Hi:

As a beginner of linux programming, I am learning to
recompile and rebuild my previous programs in Linux
with GCC/GDB.   However, there is something really
annoying me.  The code is showed as :

if ( ( d_z - current ) < MIN_ERROR && ( d_z - current
) > -MIN_ERROR)
		{
			d_z += dz_inc; 
			mp += mstep_k; 
			i_cz += step_k;			
			offset+= mstep_k;
		}
some graphical front-ends of GDB like GVD show that
the statement 

i_cz +=step_k; 

is NOT recongnised as a  statement.  The GDB just
simpily ignores it when stepping to there.   This
means the varible i_cz,which is declared as a register
int varible,  has not  updated after executing.  The
contexts work well and this part of code runs
perfectlly when compiled with VC in Windows.

Could someone give me an idea about this problem?  I
would be very grateful...

Frank Zhao

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: Why GCC/ GDB ignore a normal C statement?

[D.Venkatasubramanian, Noida]

Hi,

Did you use some optimization during compilation. If yes, then that
could be the problem. Optimization should be used only for the final
release. This is a common mistake made by new users.

Venky

On Mon, 2003-05-05 at 17:02, Huaxia Zhao wrote:
> Hi:
> 
> As a beginner of linux programming, I am learning to
> recompile and rebuild my previous programs in Linux
> with GCC/GDB.   However, there is something really
> annoying me.  The code is showed as :
> 
> if ( ( d_z - current ) < MIN_ERROR && ( d_z - current
> ) > -MIN_ERROR)
> 		{
> 			d_z += dz_inc; 
> 			mp += mstep_k; 
> 			i_cz += step_k;			
> 			offset+= mstep_k;
> 		}
> some graphical front-ends of GDB like GVD show that
> the statement 
> 
> i_cz +=step_k; 
> 
> is NOT recongnised as a  statement.  The GDB just
> simpily ignores it when stepping to there.   This
> means the varible i_cz,which is declared as a register
> int varible,  has not  updated after executing.  The
> contexts work well and this part of code runs
> perfectlly when compiled with VC in Windows.
> 
> Could someone give me an idea about this problem?  I
> would be very grateful...
> 
> Frank Zhao
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com

Re: Why GCC/ GDB ignore a normal C statement?

[Jim Robertson]

On Tue, May 06, 2003 at 02:32:40PM +0530, D.Venkatasubramanian, Noida wrote:
> Hi,
> 
> Did you use some optimization during compilation. If yes, then that
> could be the problem. Optimization should be used only for the final
> release. This is a common mistake made by new users.

This may be getting (a little) off topic, but I disagree with the
above.  Only turning on optimizations for a "final release" can have
unexpected consequences.  Optimizations have a way of uncovering bugs
that go undetected in non-optimized code.  At a minimum, testing should
be done with optimizations.  Preferably, all development is done with
optimizations.

Jim


-- 
-----------------------------------------------------------------------------
Jim.Robertson@Motorola.com

Re: Why GCC/ GDB ignore a normal C statement?

[Eli Zaretskii]

> Date: Tue, 6 May 2003 07:51:59 -0500
> From: Jim Robertson <robertso@somerset.sps.mot.com>
> > 
> > Optimization should be used only for the final
> > release. This is a common mistake made by new users.
> 
> This may be getting (a little) off topic, but I disagree with the
> above.  Only turning on optimizations for a "final release" can have
> unexpected consequences.  Optimizations have a way of uncovering bugs
> that go undetected in non-optimized code.  At a minimum, testing should
> be done with optimizations.  Preferably, all development is done with
> optimizations.

I certainly second that.  I do all my debugging builds with the full
set of optimizations options.  Modern debuggers no longer require you
to choose between -g and -O; GDB certainly doesn't.

A program compiled with and without optimizations are actually twio
very different programs.  So all of your test runs actually test a
program that is different from what you are going to ship.

Someone wise once compared testing an unoptimized program, then
turning on optimization for the release to learning to swim in shallow
waters with all the safety gear on, then throwing away that gear when
you first plunge into the deep.

RE: Why GCC/ GDB ignore a normal C statement?

[D.Venkatasubramanian, Noida]

>-----Original Message-----
>From: Eli Zaretskii [mailto:eliz@elta.co.il]
>Sent: Tuesday, May 06, 2003 10:43 PM
>To: robertso@somerset.sps.mot.com
>Cc: D.Venkatasubramanian, Noida; delzhao_linux@yahoo.com;
>gdb@sources.redhat.com
>Subject: Re: Why GCC/ GDB ignore a normal C statement?
>
>
>> Date: Tue, 6 May 2003 07:51:59 -0500
>> From: Jim Robertson <robertso@somerset.sps.mot.com>
>> > 
>> > Optimization should be used only for the final
>> > release. This is a common mistake made by new users.
>> 
>> This may be getting (a little) off topic, but I disagree with the
>> above.  Only turning on optimizations for a "final release" can have
>> unexpected consequences.  Optimizations have a way of uncovering bugs
>> that go undetected in non-optimized code.  At a minimum, 
>testing should
>> be done with optimizations.  Preferably, all development is done with
>> optimizations.
>
>I certainly second that.  I do all my debugging builds with the full
>set of optimizations options.  Modern debuggers no longer require you
>to choose between -g and -O; GDB certainly doesn't.
>
>A program compiled with and without optimizations are actually twio
>very different programs.  So all of your test runs actually test a
>program that is different from what you are going to ship.
>

I never said that optimizations should not be turned on during testing,
just that, during development, when you are uncovering logical errors
and want to set breakpoints, it is easier without optimizations.
Debugging with all optimizations can result in abnormal jumps, as is
expected due to instruction scheduling.

Definitely, thorough testing should be done with all optimizations
turned on, before the product is released.



>Someone wise once compared testing an unoptimized program, then
>turning on optimization for the release to learning to swim in shallow
>waters with all the safety gear on, then throwing away that gear when
>you first plunge into the deep.
>

Re: Why GCC/ GDB ignore a normal C statement?

[Eli Zaretskii]

> From: "D.Venkatasubramanian, Noida" <dvenkat@noida.hcltech.com>
> Date: Thu, 8 May 2003 10:37:27 +0530
> 
> Debugging with all optimizations can result in abnormal jumps, as is
> expected due to instruction scheduling.

I find this not a grave problem, although it does take some time to
become accustomed to.  The benefit is that I always test and debug the
same program I'm going to release, and never have to retest due to a
different build.

Re: Why GCC/ GDB ignore a normal C statement?

[Felix Lee]

Perhaps gdb could be a little more informative about nonlinear
flow?  Not everyone is going to be familiar with what goes on
with instruction scheduling.  I do know, and it still confuses me
sometimes.

It doesn't have to be anything complicated, just stuff like:
print "(line 11 was optimized away)" if doing "step" goes from
line 10 to line 12, there are no machine instructions for line
11, and line 11 isn't just comments.  For expert users, this
could be reduced to printing a "*" in front of line 12.  Or
whatever.

I'd also find it helpful if gdb somehow marked source lines that
were attached to nonconsecutive machine instructions.

The idea is to give just a little more information so I don't
have to spend energy guessing so much.
--