Nemiver activity report

[Dodji Seketeli <dodji seketeli org>]

Hello,

This is a just a little note to let you know about what's being at
Nemiver-central recently.

As you probably know by now, we have released 0.9.1 a couple of weeks
ago.  Packages have started to hit distros here and there and we have
even started getting bug reports for that new version.  Nothing
catastrophic so far, though.

[Variables Monitoring]

On the side, I went forward on the monitor-variable branch[1].  I have
added the infrastructure as well as UI bits to start seeing stuff.
But then I hit a little wall.  It looks like I'll need to hammer the
way we handle the life time of IDebugger::Variable.

That is, when an instance of IDebugger::Variable is backed by a
"Variable Object" in GDB, there are two life cycles to handle.  The
one of the IDebugger::Variable and the one of the Variable Object in
GDB (aka varobj).  Of course, I could just decide the leak the varobj
but I dislike that idea.  :-)

For historical reasons, varobjs are currently deleted at a certain
fixed numbers of points.  Basically, varobjs of local variables are
deleted when we leave the current frame, and varobjs of an expression
evaluated in the variables (or expression) evaluator are deleted when
we leave the evaluation.  It was working well enough so I didn't think
of having anything more sophisticated.

But now, new usage cases are emerging with this feature.  After the
user has evaluated an expression in the evaluator dialog, she can
choose to stick that expression in the (variable) monitor.  [Really, I
think I should call the feature Expression Monitoring, instead of
Variable monitoring].  That is, the IDebugger::Variable resulting from
the evaluated expression is passed to the expression monitoring
component.  So at the point where the expression monitoring component
is done with that IDebugger::Variable, it's destroyed.  At that point
the related varobj should be deleted as well.

Thus I need to implement this life cycle management before I get back
to expression monitoring proper again.  I have file an enhancement
request[2] in bugzilla to track this new task.

[Support OpenOCD/JTAG remote debugging]

Nemiver currently supports remote debugging through gdbserver.  The
user has to run a gdbserver on the remote target, and let Nemiver
connect to it via TCP/IP, for instance.

There have been a couple of requests to support a setup where the
target is linked to the host via a JTAG connection.  In that case, an
OpenOCD[3] daemon knows how to talk to the target via JTAG, and
exposes a gdbserver-compatible interface to the host.  The user could
thus let Nemiver connect to the gdbserver-like port on which the
OpenOCD daemon listens.

Supporting this means that Nemiver has to issue a couple of additional
command to the OpenOCD daemon, compared to what happens with a normal
gdbserver connection.

Tomasz Moǹ has volunteered to test the patches I'd cook for him and
send me back logs, as I don't have such a hardware setup.  I have
therefore created a branch[4] and an enhancement request[5] in
bugzilla to track this feature.  There is code there that you can
already test and give me feedback.  If you are interested, please give
feedback on the bug.

Apart from that, I have been involved in the usual bug fixing here and
there.

Thank you for reading.  You might now return to your regular
programming.

Happy Debugging!

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=542503
[2]: https://bugzilla.gnome.org/show_bug.cgi?id=663959
[3]: http://openocd.sourceforge.net/doc/html/GDB-and-OpenOCD.html#GDB-and-OpenOCD
[4]: http://git.gnome.org/browse/nemiver/log/?h=remote-load-on-connect
[5]: https://bugzilla.gnome.org/show_bug.cgi?id=664743

-- 
		Dodji