Editing source while debugging
ghost at cs.msu.su
Sun Dec 31 00:17:05 UTC 2006
On Sunday 31 December 2006 03:07, Cavalaria Christophe wrote:
> On Sunday 31 December 2006 00:27, Jens Dagerbo wrote:
> > On Saturday 30 December 2006 23:56, Vladimir Prus wrote:
> > > Hi,
> > > I start to wonder what's the right thing to do if a user modifies a file
> > > while debugging. In Java (Eclipse), the IDE tries to modify the running
> > > application with the new code, but it's not possible for C++/gcc/gdb.
> > >
> > > There's concrete problem. You have breakpoint set in KDevelop (and in
> > > gdb) and foo.cpp:10. You add a line on top of the file. Kate moves the
> > > breakpoint marker to foo.cpp:11. For the next debugger run, the gdb
> > > breakpoint will be set at foo.cpp:11, but what to do for *this* debug
> > > session.
> > >
> > > 1. Moving gdb breakpoint to foo.cpp:11 is not a good idea. As line
> > > 11 in old foo.cpp, that's compiled into the currently debugged
> > > application, is not the same line as line 11 in new foo.cpp.
> > > 2. If we don't move gdb breakpoint, and gdb stops on it, it will report
> > > line 10, while the actual code being executed is now at line 11.
> > >
> > > It seems that after breakpoint is moved, debugging the application does
> > > not make sense any more. Should we perhaps mark moved breakpoints in some
> > > way, disable them, and enable only for the next debugger run?
> > >
> > > - Volodya
> > I'm a fan of simple solutions that work.. either disallow editing while
> > debugging (not sure we can do that) or simply flush all breakpoints in a
> > file if the user starts editing it while the debugger is running.
> Yuck, in my opinion, don't do that! There is that option in Delphi ( make code
> read only during debugging ) and I've only used it for a few minutes before
> disabling it. It's much better for the user to deal with somewhat incorrect
> breakpoints than to prevent editing during debugging.
> Simple solution : leave it as it is and add a "code changed, do you want to
> rebuild it?" when the user tries to resume the program beeing debugged. This
> should be enouth of a warning that future breakpoints might not be as
> accurate as possible.
Then, we'd need a way to ask Kate not to move markers corresponding to breakpoints.
Otherwise, we'd have some complexity devoted to moving breakpoint, when in fact
we don't support this at all.
More information about the KDevelop-devel