This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major improvement to the Xconq kernel
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Jim Kingdon <kingdon at panix dot com>
- Cc: hronne at comhem dot se, <xconq7 at sources dot redhat dot com>
- Date: Thu, 13 Nov 2003 22:05:00 -0500 (EST)
- Subject: Re: Major improvement to the Xconq kernel
On Thu, 13 Nov 2003, Jim Kingdon wrote:
> > A new path-finding code by Peter Garrone has just been checked in. It uses
> * One case where an infantry just sat there in one my my towns, about
> 3-5 hexes short of its destination. It was apparently using up its
> ACP on each turn. Won't be able to do anything about this unless I
> notice it happening again (as in, I'm not even 100% sure it was
> really a bug I saw).
I've seen this happen too (with the new path code). If you look at
the unit's info display, does it list the movement task with a "x
0" next to it for the entire turn?
> * One SIGSEGV. Most interesting part of the stack trace follows.
> Because the default compilation uses -O, it is hard to quickly
> look at the variables at that point.
For the modern GNU C compilers, configure reports -O as part of
the default CFLAGS. (I think I heard somewhere, perhaps on the
gcc list, that -O and -g should now be able to work together
without significant problems.) My experience has been that if
the two are used together, then sometimes you need to step a few
lines before GDB will "backtrack" to the variable in question and
show its assigned value; I assume that this is simply because the
optimizer reorders instructions and it is harder to know when to
associate a line with an instruction.
I can filter -O out of the default CFLAGS for the GNU compilers,
if there is a consensus that this should be done. I know that
Peter is leary about debugging optimized code.
Eric