Editing source while debugging

Jens Dagerbo jens.dagerbo at swipnet.se
Sun Dec 31 00:29:19 UTC 2006


On Sunday 31 December 2006 01:17, Vladimir Prus wrote:
> 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. 

.. which we cannot do. KTE doesn't offer us this option. In fact, there is no 
way we can differentiate between "The user added/removed a breakpoint" (which 
we want to handle) and "The user is typing so the markers are moving".

The only thing I can see us realistically handling is my second option: as 
soon as we detect typing in the active file when the debugger is running, 
flush all its breakpoints - all bets are off, nothing we knew about 
breakpoint positions is valid any longer.

Yeah, it sucks, but at least it will be consistent.

// jens







More information about the KDevelop-devel mailing list