Mail Archives: cygwin/2003/03/29/13:17:42
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/
- Raw text -