Given the current state of Valgrind and GDB how can we make things even better and smoother? Put some Valgrind and GDB hackers in the same room and let them discuss the technical details needed on each side. Come and help us brainstorm some crazy and fun ways to make the Valgrind/GDB combo even cooler and more powerful.
Setting up Valgrind with GDB is a bit more work than some would like. Wouldn't it be nice if all one would need to do inside GDB would be:
(gdb) target valgrind (gdb) run
Exactly how one gets here though ... may need changes to both GDB and Valgrind. Can "target valgrind" also work nicely with ssh somehow, so you can gdb a valgrind on a different machine.
How can we get extended-remote features from Valgrind? In particular it would be nice to have multi-inferior working. This is tricky, though, because in the Valgrind model each new inferior would have its own gdbserver. Brainstorm solutions.
Can we get Valgrind to handle non-stop? This is the direction GDB is moving towards.
Right now Valgrind provides "monitor" commands to control it. Could instead let Valgrind create real commands with completion; perhaps via Python. Is this worth doing; and how would we do it?
Likewise is it interesting for memcheck to provide a convenience function that can be used to tell whether some memory is valid? On the GDB side it might be interesting if the function could work with ASAN or gdb-heap as well.
Given that Valgrind sees everything you get unlimited "hardware" data watchpoints. Do you want more?
Reverse debugging using Valgrind.
Can GDB put breakpoint tracepoint expressions in a Valgrind inferior that VEX would JIT?
Given the work on GDB catch syscall support are there any more catch targets that Valgrind could/should provide?
Speakers: Tom Tromey