jens.dagerbo at gmail.com
Thu Apr 20 11:06:08 UTC 2006
On 4/20/06, Vladimir Prus <ghost at cs.msu.su> wrote:
> I have some issues with current watchpoint logic in KDevelop, but before
> changing it completely wanted to discuss this on list.
> Problem 1. If I set a watchpoint on anything but a global var, and then
> restart KDevelop, I immediately get error that expression is not valid, when
> KDevelop tries to insert that watchpoint.
> Problem 2. Suppose I have a function like this:
> void do_that(My_class* ptr)
> ptr->i = .....;
> I notice that ptr->i holds a valid value at the moment, and want to set
> watchpoint on 'i', to detect where that value is damaged. Unfortunately, as
> soon as gdb leaves 'do_that', gdb reports:
> Watchpoint N deleted because the program has left the block in
> which its expression is valid.
> This is technically correct, but makes watchpoints unusable.
> In fact, when debugging with console gdb, I've learned to always set
> breakpoints on address.
> How about making KDevelop behave like this:
> 1. For each watchpoint, KDevelop evaluates the address and sets gdb watchpoint
> on the address. The original expression is remembered by KDevelop.
> 2. If the address is in the current stack frame, then leaving the stack frame
> deletes watchpoints.
> 3. When debugger has stopped, all watchpoints end up in disabled state. Later,
> user can re-enable any watchpoint. In this case, the stored expression value
> will be reevaluated again.
> 4. If gdb can't set hardware watchpoint, we should produce a big error
> message, saying "While gdb has software watchpoints, they are too slow to be
> Any problems with the above?
> - Volodya
I have no problems, you seem to have thought it through. :)
I'm curious about point 2 though. Removing a local watchpoint when
leaving the stack frame certainly makes sense, but will it possible
for KDevelop to remember the expression and recreate the watchpoint
when entering the same scope again?
More information about the KDevelop-devel