[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Watchpoint issues
From:       "Jens Dagerbo" <jens.dagerbo () gmail ! com>
Date:       2006-04-20 9:05:02
Message-ID: 982543070604200205r43df044qd96e2bcc17f536a6 () mail ! gmail ! com
[Download RAW message or body]

On 4/20/06, Vladimir Prus <ghost@cs.msu.su> wrote:
>
> Hi,
> 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
> usefull".
>
> 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?

// jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

[prev in list] [next in list] [prev in thread] [next in thread]