Re: [Nemiver-list] Variable monitor widget

[Jonathon Jongsma <jonathon domain hid>]

Dodji Seketeli wrote:
> Hey Jonner,
>
> Jonathon Jongsma a écrit :
>
> [...]
>
> > I am thinking about starting to implement a variable monitor widget
> > (aka a variable 'watch' widget) for nemiver.  If anyone has any
> > comments about how it should be implemented, feel free to share them.
>
> FWIW, at an 'engine' level, I think it would be interesting to base 
> the widget on the IVarListWalker interface. That interface can update 
> the state of a defined set of variables upon a call on its 
> IVarListWalker::do_walk_variables() entry point.

yes, that's the plan.

> I do have some questions concerning the user interaction. How do you 
> think we should do to add variables to the monitor ? I was thinking 
> about being able to type in the monitor widget, the name of the 
> variable you wanted to monitor. It could also be nice to be able to 
> select a variable in the source code editor, right click and hit "add 
> to monitor", or something like that. What do you think ?

Yes, it would definitely be nice to be able to add a new variable by 
simply typing into the widget.  Sort of like how we add environment 
variables in the 'Execute' dialog (although it'd be nice to not have to 
click an 'add' button first).  Also, I think we definitely want to be 
able to right-click something in the editor and add it to the monitor, 
but that feature could probably come later since it will likely be a 
little tricky to get right (e.g. making sure it does the right thing 
when you right click on something like foo->bar.x).

> Then there is the problem of "out of scope" detection and reporting.
>
> Suppose the user is stepping in a function foo_func() and wants to 
> monitor a variable foo that is local to that function foo_func(). What 
> happens when the current instruction pointer suddenly goes out of the 
> scope of the function ? I think we should detect that and visually 
> flag the variable somehow, showing the user that the variable went out 
> of scope. I have no idea how to present that to the user. Even the 
> engine part of is not clear to me yet because error reporting on 
> variable query is pretty weak in our infrastructure at the moment. So 
> this is something we need to address.

Yes.  I guess the 'right' way to deal with this is probably to revamp 
our gdb interaction a bit so that we can actually report and receive 
errors reliably.  But currently we don't really have any way to do 
this.  I suppose that one hacky workaround at the moment might be 
something like this:
- whenever the debugger stops, go through the list of variables in the 
monitor and set each one's value to something like "<out of scope>"
- query all of the variables
- when we receive a variable undated signal, update its to the real value.
This way, any variables that went out of scope will display an error 
indication to the user since they won't get a response from querying gdb 
for its new value.  The downsides of this option are that it's an ugly 
hack and that the variable values will probably flicker between "<out of 
scope>" and the real value on each step.  But I don't see a much better 
option until we get some improved error reporting... 

Another hacky workaround could be:
- Have a set of flags indicating which variables in the monitor have 
been updated
- each time the debugger stops, clear the flags and then query each variable
- add a timeout callback for X seconds in the future, when you would 
expect all variable queries to be finished.
- when a variable gets updated, set its flag
- in the timeout callback, check which flags didn't get set and change 
their values to be "<out of scope>" or something similar.
The disadvantages of this scheme are: How do you determine the value for 
X seconds when all of the variable querying should be completed?  This 
scheme also seems likely to have some race conditions (e.g. what happens 
if X is relatively long and the user steps the debugger before the 
timeout expires and then the timeout handler fires while we're in the 
middle of querying the list of variables the next time?)

> There is also the need to be able to be able to monitor "locations" 
> pointed to by addresses, instead of just variable names. I am not sure 
> how to present that either.

hm, what do you mean by this exactly?  Do you mean the user should be 
able to type something like "0xbf445566" into the monitor widget and 
have it display the data at that memory location?  or using an explicit 
cast (e.g. "(float*)0xbf445566")?  How does your use case differ from 
the memory view widget?

> I am not sure this helps much, but I thought I'd be good to write 
> about my current state of thoughts on the matter :-)

Thanks.  btw, I was hoping to get a good start on this by doing some 
hacking at GUADEC, but unfortunately I had almost no time to hack while 
I was there, so I haven't really made any progress on this.