Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re: [cdt-debug-dev] Bring Back "Add Watchpoint (C/C++)" for CDT 2.1.1? 
> 
> The Run->Add Watchpoint (C/C++) menu item (in CDT 1.x) was removed from
> CDT 2.0.  We (Altera) shipped our Nios II 1.1 IDE (last summer) based on
> CDT 1.2.1.  Now we're in the middle of upgrading to CDT 2.1 for our next
> release, and we don't want to take watchpoints (on local variables) away
> from our users.
> 
> I understand that "Toggle Watchpoint" has been added for global
> variables in the Outline view.  But our customers used the Add
> Watchpoint feature to set watchpoints on local variables.  I also
> understand that watchpoints on local variables are not persistent
> between debugging sessions.  We're aware of the "bug" where watchpoints
> on local variables remain in the Breakpoints view, but don't work in
> subsequent debugging sessions.  But we feel that it's more important to
> keep this buggy functionality in than remove it all together.  (I would
> like to try to fix this bug in the future and, of course, contribute the
> fix back to the CDT.)
> 
> Would anyone object to this being added back for the CDT 2.1.1 release?
> 
> I exchanged email with Mikhail Khodjaiants about this, and he suggested
> that we add it back in as an "Add Watchpoint" action in the Breakpoints
> view, so there won't be two similar editor actions when "Toggle
> Watchpoint" is added as an editor action in CDT 3.0.  This makes sense
> to me.
> 

Cc: cdt-dev, not all folks follow cdt-debug-dev

CDT-2.1.1:
  I would have prefer, the issue to be raise in CDT-2.1 ... but hey! ...
  No objection on my part to put an "Add Watch Expression" action, so late in the game.
  I guess, we can consider this to be a ... regression fix 8-)

========
A few more points:
(a)
The Add action did not provide any validation and was not well integrated in term of UI:
- for example, user would enter in the text dialog an address ... crashing gdb or the embedded target
  because address watch point has a different semantic, then expression watchpoint.

User enter "0x800fa4" in the text field ...
(gdb) watch 0x800fa4                <----- REALLY BAD
(gdb) watch *0x800fa4               <----- GOOD
 
Note: To make this more clear, maybe this action should be name "Add Watch Expression"
      Or we could do some basic sanity check on the expression, if an integer value, do the right
      thing in gdb/mi.

(b)
Local variables watchpoint are not very well understood by the Users.  When the variable,
or when a variable in the expression, becomes out of scope, the watchpoint is effectively 
deleted (meaning you may not stop if you reenter the function).
And as you pointed out, when the user restarts the debug session, unless
the variables are in scope .. the watchpoints can not be reset ... more frustration.

Note: We may have some scheme that can make this transparent for the user by implanting
     some __hidden__ breakpoint and do some work under the cover with the AST parser.
     But ...

So for the future(CDT-3.0):
When "Toggle Action" action is trigger, we will use the AST parser to examine
the selection in the CEditor and some analysis on the best course of action.
If the selection is on a global variable ... we are good to go,  if it is on
a local variable ... we could go from warning the user to implementing
more complex scenarios ...

in this satisfactory or you still would like to have a liberal
"add Watch expression" that the user could enter any expression ?

Back to the top