Fwd: Helping with KDE4 (valgrind)

[Julian Seward]

> 1) I'm interested to hear if you have any plans to provide a bidirectional
> machine interface for valgrind.  Currently, in order to make Valgrind work
> well with tools such as kdevelop, the xml output is preferred as it is the
> only output that provides the full path for source files, plus it is easier
> and more reliably parsed.
>
> However this doesn't allow attaching debugger sessions as there is no way
> for valgrind to receive input (a documented limitation).  GDB solves this
> with an interactive command line approach and their machine interface
> syntax.  Could valgrind be made to provide such a command line interface,
> preferably with a machine interface syntax as well (perhaps even using
> gdb's syntax, or an xml syntax)?
>
> This might also open up the possibility of querying a paused valgrind for
> information about valid value and valid address of certain memory
> addresses, and backtraces for its allocation/freeing/etc, which could be
> integrated into the debugger support (eg. alongside a variable viewer
> widget we could display which variables are not initialised/allocated).

Such ideas have been floated from time to time, and they sound doable.
One thing that would really help is to have a specific proposal for
functionality available for discussion.  I have seen vague suggestions
about this in the past ("it would be nice for V to be externally 
controllable") but nothing at the level of specificness where we can
figure out the consequences and effort needed to implement.

> 2) Is the Omega tool (http://www.brainmurders.eclipse.co.uk/omega.html for
> those who haven't come across it) going to be added to Valgrind svn? It
> looks like a promising tool, although I'm having problems with false
> positives in QMap at the moment.

No plans at the moment.  I believe none of the V developers have looked at it
in much detail.  Any assessment/evaluation you can make of it would be useful.

J