Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E85E33A.25183742@doe.carleton.ca>
Date: Sat, 29 Mar 2003 13:17:30 -0500
From: Fred Ma <fma AT doe DOT carleton DOT ca>
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gdb discrepancy in c++ iterators
References: <Pine DOT GSO DOT 4 DOT 44 DOT 0303291300360 DOT 21921-100000 AT slinky DOT cs DOT nyu DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Igor Pechtchanski wrote:

> Depending on the optimization level you used to compile the program (and
> on the flags in the gcc specs file, and the gcc compilation options, which
> are surely different on the two systems), it's quite possible gdb got
> confused about where in the program you were with respect to the (probably
> inlined) execution of vi.begin() (or, for that matter, the copy
> constructor).
>
> As possible workarounds: Did you consider trying to compile without
> optimization?  Also, in the original program, does the bug you're looking
> for manifest itself if you introduce an extra counter into the loop?  If
> so, you could use that counter's value as the condition for the
> breakpoint.  There are also counted breakpoints in gdb that you could make
> use of...
>         Igor

Yes, I've read that optimization can make things unpredicatable
and confusing for debugging.  I didn't turn on optimization.  But this
is not just a debugger confusion.  The program misbehaves.
I've embedded code to print out the vector elements after some
action on it.  No changes take effect (on cygwin), probably due
to the differing iterator values (aggregate values, that is).  On
solaris, the program runs as expected i.e. the changes take
effect.  Exactly the same code, almost the same compiler.

I'll try some of the gdb features you pointed out, but since the
problem manifests itself in the program behaviour (and not just
when using gdb), it would be a surprise to see it as a gdb
problem (or my use of it).

Thanks for the pointers.

Fred

--
Fred Ma, fma AT doe DOT carleton DOT ca
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/