From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: preprpcessor for overiding gcc optimation switch
Date: Tue, 20 Jun 2000 14:40:55 +0100
Organization: Customer of Planet Online
Lines: 38
Message-ID: <394F7467.6340126B@phekda.freeserve.co.uk>
References: <Pine DOT LNX DOT 4 DOT 21 DOT 0006030531400 DOT 1081-100000 AT roadrunner DOT grendel DOT net> <83zop3o170 DOT fsf AT mercury DOT bitbucket> <25c58271 DOT fc969396 AT usw-ex0104-033 DOT remarq DOT com> <8ino7d$i9b$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
NNTP-Posting-Host: modem-9.silicon.dialup.pol.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: newsg3.svr.pol.co.uk 961509612 3099 62.136.13.9 (20 Jun 2000 14:00:12 GMT)
NNTP-Posting-Date: 20 Jun 2000 14:00:12 GMT
X-Complaints-To: abuse AT theplanet DOT net
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello.

Hans-Bernhard Broeker wrote:
> 
> batchex <thedark1NOthSPAM AT phreaker DOT net DOT invalid> wrote:
> 
> > The reason I'm asking this cause in one of my project, one (only
> > one) of the source file, when compiled with optimation, then try
> > to debug a function contained in that file in gdb, it will give
> > errorneous results.
[snip]
> Or was that function an inline assembly one, by any chance? If so,
> it's probably just plain buggy if optimization prevents you to run the
> debugger over it.

When I have done debugging on libsocket, I found that normal breakpoints
failed to work sometimes. I found that hardware breakpoints were much more
successful - e.g. "hb lsck_init". Otherwise gdb would not stop in the
routine that I asked it to. I guessed that this was some problem due to
libsocket calling in Windows virtual device drivers. It might be worth
trying a hardware breakpoint instead of a software breakpoint.

> > I forgot if gdb crashed while debugging it or not, but I remember
> > peculiar flow of my program.
> 
> 'Peculiar flow' of control may not mean anything bad, while you're
> debugging an optimized program.

I've found that looking at the disassembly can be helpful to see if
anything weird is going on. The peculiar flow is a little distracting. It
seems to occur more at the start of a function, in my experience. In the
middle of functions things generally seem to be "smoother".

Bye,

-- 
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]