On Mon, Nov 12, 2007 at 03:52:01PM -0200, Alexandre Oliva wrote: > On Nov 12, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > > (We may already have lost some information, though. For example, given: > > > i = 3; > > f(i); > > i = 7; > > i = 2; > > g(i); > > > we may well have lost the "i = 7" assignment, so "i" might appear to > > have the value "3" right before we assign "2" to it, if we were to > > generate debug information right then.) > > Yup. And even if we could somehow preserve that information, there > wouldn't be any code to attach that information to. There might be > uses for empty-range locations in debug information, but I can't think > of any. Can anyone? It's something we could try to preserve, and > with my design it would be quite easy to do so, but unless it's useful > for some purpose, I think we could just do away with it.
If we drop the "i = 7" assignment, then a debugger could have a consistent view of what is going on if, given i = 3; // line 10 f(i); // line 11 i = 7; // line 12 i = 2; // line 13 g(i); // line 14 "next" would step from line 10, to 11, to 12, to 14. We would not be able to stop after the execution of a no-longer-existing statement; if we could stop at the beginning of line 13, it would imply that line 12 has run and line 13 has not, which does not reflect what the optimized code is doing. We don't do it this way at the moment; we would be able to set a breakpoint at line 13. But perhaps the right way to think about your project, Alexandre, is to make things match up at the point where the gdb user can observe the state, and consider dropping observable points where the states will not match.
