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: <3E85D9FA.AC72F2DA@doe.carleton.ca>
Date: Sat, 29 Mar 2003 12:38:02 -0500
From: Fred Ma <fma AT doe DOT carleton DOT ca>
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: gnu.gcc.help,comp.unix.programmer
To: cygwin AT cygwin DOT com
Subject: Re: gdb discrepancy in c++ iterators
References: <Pine DOT GSO DOT 4 DOT 44 DOT 0303291115320 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:

> On Sat, 29 Mar 2003, Fred Ma wrote:
>
> > Hello,
> >
> > I'm having the following problem only on cygwin,
> > not on solaris 8.  I have a sanity-check program:
> >
> >      #include<vector>
> >      #include<iostream>
> >      using namespace std;
> >      int main(void)
> >      {
> >         vector<int> vi(3);
> >         vector<int>::iterator it_vi = vi.begin();
> >         cout << "Hello world.";
> >      }
> >
> > I compile it with gcc 3.2 use
> > gdb2003-03-03-cvs(cygwin-special) to view
> > vi.begin() and it_vi.  They are different:
> >
> >      (gdb) p vi.begin()
> >      $1 = {<iterator<std::random_access_iterator_tag,int,int,int*,int&>> =
> >                  {<No data fields>}, _M_current = 0xc7e44589}
> >      (gdb) p it_vi
> >      $2 = {<iterator<std::random_access_iterator_tag,int,int,int*,int&>> =
> >                  {<No data fields>}, _M_current = 0xa041de0}
> >
> > Why are they different?  If I actually dereference the iterators,
> > they contain the same thing.  But I want to deal with the iterators
> > themselves.  In particular, I want a conditional breakpoint to trigger
> > when it_vi==vi.begin()+4.  gdb won't let you add 4 to a random
> > access iterator, so I have to use the _M_current member data.
> > Since they are not the same above, I can't do that.  Thanks for
> > any light on why they differ.
> >
> > Fred
>
> Umm, you do know that calling vi.begin() will create a *new* iterator,
> right?  As for it working on other systems, they may have different
> implementations of STL iterators.
>         Igor

Yes, I know that.  I'm comparing it on a different system but
with the same version of gcc, so I expect the STL implementation
to be the same.  I have to qualify that; the cygwin version is
gcc3.2 20020927 (prerelease).  The solaris version is 3.2.1,
and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
probably a tenative version of the solaris version.  But I don't
expect great changes, at least not as big as the definition of
_M_current.  If iterators are suped up pointers, then _M_current
is the primitive pointer that is suped up.  From the properly
functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
same value for _M_current.  If I dereference _M_current in
either iterator, I get the right object value.  If I try this on cygwin,
*it_vi._M_current returns the right value, but
*(vi.begin()._M_current) is an error because the memory
location can't be accessed.  In the actual program that
I'm trying to debug, none of the changes made to a aggregate
vector elements via it_vi seem to have any effect, probably
because of the differing _M_current values (in that case,
vi.begin()._M_current is pointing to valid memory space).

About the fact that the iterators are different, gdb's print
command prints the object itself, including data members,
*not* the address of the object.  So the fact that the iterators
are different should not make the objects' value different.

Another strange "clue", if it is that:  if I print *it_vi._M_current
in the full blown program, vi.begin()_M_current actually changes
values (by itself) so as to be the same as it_vi._M_current.
Very  bizzare.

Fred

P.S.  The gdb version on cygwin (at top) is relatively
recent.  In contrast, on solaris8 (where things seem to
behave right), it's gdb 4.17, copyright 1998.

--
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/