I do have to take exception to James Molloy's assessment of the variable "n"
as "optimized away" because the debug info clearly thought it wasn't. (The
"n=0" shows that the debug info described some kind of location; if "n" was
indeed optimized away, it should have said so. Either the debug info does
have a bug--giving a location for a nonexistent variable--or something else is
interfering with our expectations.)
It is very easy for people to dismiss problems with optimized-code debugging
with a "well, what did you expect??" kind of attitude. Actually there are three
broad categories that can apply to any such issue.
(a) The compiler is trying to keep the debug info in sync with the generated
code, but got it wrong. This is a correctness bug.
(b) The compiler isn't bothering to keep the debug info in sync with the
generated code, even though it reasonably could do so. This is a
(c) Optimization has made the situation too complicated for the debug info to
reasonably keep track of things. This happens.
There is some slop between the categories, because there are judgement
calls involved in whether something is bad enough to be a bug or is more of
a heuristic that isn't as good as we'd like; equally, there are judgement calls
in what's a "reasonable" degree of effort to keep track of complicated cases.
Blithely tossing every problem into the third category is
inappropriate. I spent
nontrivial time (on a previous compiler project) tracking down optimized-code
debugging issues, and probably half of the time I could do something easy to
address it. Sometimes the compiler was attaching the wrong source location
(bug), sometimes it wasn't bothering to keep track at all even though
it would be
easy (quality of implementation). In a few cases, generating accurate debug
info required extra analysis, and once or twice we went to that extra trouble;
the rest of the time, it didn't seem worthwhile (judgement calls).
Getting down to the specifics of this case, I downloaded the example programs
and tried them as described. I got the same behavior as Seb described.
As for our friend "n=0", after I hit the breakpoint I tried stepping
once. At that
point, "print n" showed "53" just as we would want. While it would be ideal to
see "n=53" at the breakpoint, sometimes debug info and function prologs don't
line up exactly, and stepping sometimes causes things to become more sensible.
So, I think the 32-bit debug info is doing something reasonable, if not exactly
what you would want.