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 _______________________________________________ nemiver-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nemiver-list
